# |
Aug 22nd 2019, 11:15 |
conehead |
That is exactly what I am trying right now. |
# |
Aug 22nd 2019, 11:14 |
alexdd55976 |
and avoids some load on post query pagination |
# |
Aug 22nd 2019, 11:14 |
alexdd55976 |
super quick |
# |
Aug 22nd 2019, 11:14 |
alexdd55976 |
did you think about datatables, combined with ajax calls and json repsonses? |
# |
Aug 22nd 2019, 11:13 |
alexdd55976 |
urgs |
# |
Aug 22nd 2019, 11:13 |
conehead |
Right now it would be just way faster to load 20k entries and throw them at the user than trying to paginate haha |
# |
Aug 22nd 2019, 11:11 |
conehead |
And until now it actually worked quite well. Absolutely not sure if a combined index is the right thing to use here. Just seemed to make sense here |
# |
Aug 22nd 2019, 11:11 |
alexdd55976 |
you don't wanna open this pandoras box |
# |
Aug 22nd 2019, 11:11 |
alexdd55976 |
lol.. don't touch that :) |
# |
Aug 22nd 2019, 11:11 |
alexdd55976 |
oh, ok |
# |
Aug 22nd 2019, 11:10 |
conehead |
Was hoping to switch one day. But as the systems are productive and the ids are stored in thousands of entries and in lots of versioning/history I did not want to switch all |
# |
Aug 22nd 2019, 11:10 |
alexdd55976 |
serious question. |
# |
Aug 22nd 2019, 11:10 |
alexdd55976 |
you sure that a combined index is the way to go there? |
# |
Aug 22nd 2019, 11:09 |
alexdd55976 |
was thinking about uuids .. but seems that uuids would make more sense, if used all over the place and not mixed up |
# |
Aug 22nd 2019, 11:08 |
alexdd55976 |
i have a similar approach planed in my new project |
# |
Aug 22nd 2019, 11:07 |
conehead |
it is a Unique Index combined with `model` and `foreign_key` |
# |
Aug 22nd 2019, 11:07 |
alexdd55976 |
that explains longer response time |
# |
Aug 22nd 2019, 11:06 |
conehead |
Status can be linked to different entities. And some entities have a uuid and some have an id |
# |
Aug 22nd 2019, 11:06 |
alexdd55976 |
so its a text fulltext index? |
# |
Aug 22nd 2019, 11:06 |
conehead |
No, both CHAR(36), but sometimes the CHAR just stores the id |
# |
Aug 22nd 2019, 11:05 |
alexdd55976 |
how can you have both? its a different datatype? |
# |
Aug 22nd 2019, 11:05 |
conehead |
Which imho should not be a problem |
# |
Aug 22nd 2019, 11:05 |
alexdd55976 |
thats a tough one |
# |
Aug 22nd 2019, 11:05 |
conehead |
yes |
# |
Aug 22nd 2019, 11:05 |
alexdd55976 |
? |
# |
Aug 22nd 2019, 11:05 |
alexdd55976 |
> OR |
# |
Aug 22nd 2019, 11:04 |
conehead |
The foreign_key might contain ids or uuids |
# |
Aug 22nd 2019, 11:03 |
conehead |
Urgh...I got an idea |
# |
Aug 22nd 2019, 11:03 |
conehead |
``` SELECT ( COUNT(*) ) AS `count` FROM documents Documents LEFT JOIN statuses Status ON ( Documents.id = (Status.foreign_key) ) ``` |
# |
Aug 22nd 2019, 11:00 |
alexdd55976 |
so whta the current query? |
# |
Aug 22nd 2019, 11:00 |
conehead |
@alexdd55976 yes I removed it and still takes 8 seconds. |
# |
Aug 22nd 2019, 11:00 |
conehead |
@steinkel I can check but it is not a query I perform myself. |
# |
Aug 22nd 2019, 11:00 |
alexdd55976 |
`LEFT JOIN statuses Status ON ( Status.model = 'Documents'` thats slows things down |
# |
Aug 22nd 2019, 10:59 |
steinkel |
`->counter` would allow you to tweak the query for count() |
# |
Aug 22nd 2019, 10:58 |
steinkel |
@conehead check this https://book.cakephp.org/3.0/en/orm/query-builder.html#returning-the-total-count-of-records |
# |
Aug 22nd 2019, 10:51 |
conehead |
When I remove that additional condition, SQL time is reduced from 22 seconds to 8 seconds for this query :S |
# |
Aug 22nd 2019, 10:51 |
conehead |
Oh and yes the count is actually affected as there is a condition for the model field |
# |
Aug 22nd 2019, 10:50 |
conehead |
Yes I did. The query itself is working fine and fast. When passing the query to pagination, shit hits the fan |
# |
Aug 22nd 2019, 10:50 |
steinkel |
^ count query I mean |
# |
Aug 22nd 2019, 10:49 |
steinkel |
well, you can define your pagination query |
# |
Aug 22nd 2019, 10:49 |
neon1024 |
I have a feeling that might be the Paginator doing the count, as the query passed to it has a join |