-
-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: $this->paginationTotalItemCount included on all pagination types. Too heavy for "simple" #1687
Labels
bug
Something isn't working
Comments
I'm on holiday at the mo, but will look at adding a toggle for enabling/disabling the behaviour in a release when I'm back (next month)
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Adam ***@***.***>
Sent: Thursday, March 14, 2024 7:35:44 AM
To: rappasoft/laravel-livewire-tables ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [rappasoft/laravel-livewire-tables] [Bug]: $this->paginationTotalItemCount included on all pagination types. Too heavy for "simple" (Issue #1687)
What happened?
I have just upgraded to v3.
I have some tables with nearly 1M rows and some relationships. These worked fine in V2 using simple pagination.
V3 has introduced the code:
if ($this->isPaginationMethod('simple')) {
$this->paginationTotalItemCount = $this->getBuilder()->count();
return $this->getBuilder()->simplePaginate($this->getPerPage() === -1 ? $this->paginationTotalItemCount : $this->getPerPage(), ['*'], $this->getComputedPageName());
}
The getBuilder()->count() method is very heavy on big tables. On V2 I did not have the required indexes and tables would load in milliseconds. Without indexes on V3 my tables are timing out with > 30s load time.
After adding some additional indexes, I have gotten load times down between 500ms and 10s... but it is still a big performance from from V2 in this regard.
Do we need to be getting $this->paginationTotalItemCount = $this->getBuilder()->count(); for simple pagination? I thought the whole idea of simple was to make things more performant?
How to reproduce the bug
No response
Package Version
3
PHP Version
8.2.x
Laravel Version
10.34
Alpine Version
No response
Theme
None
Notes
No response
Error Message
No response
—
Reply to this email directly, view it on GitHub<#1687>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AZATUOXO2WZ3CMZZAVB67WDYYDPFBAVCNFSM6AAAAABEVCRS7KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4DKMBZHE3TEMA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still interested in this. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
I have just upgraded to v3.
I have some tables with nearly 1M rows and some relationships. These worked fine in V2 using simple pagination.
V3 has introduced the code:
The
getBuilder()->count()
method is very heavy on big tables. On V2 I did not have the required indexes and tables would load in milliseconds. Without indexes on V3 my tables are timing out with > 30s load time.After adding some additional indexes, I have gotten load times down between 500ms and 10s... but it is still a big performance from from V2 in this regard.
Do we need to be getting
$this->paginationTotalItemCount = $this->getBuilder()->count();
for simple pagination? I thought the whole idea of simple was to make things more performant?How to reproduce the bug
No response
Package Version
3
PHP Version
8.2.x
Laravel Version
10.34
Alpine Version
No response
Theme
None
Notes
No response
Error Message
No response
The text was updated successfully, but these errors were encountered: