we made some testing - with product info. search %textstring% tooks 13 sec.
After analyse dabase with pgbadger, explain me the most slower normalised query tooks 7,5 second.
and investigate to code and looks info window query data twice
chat with hieplq
....one time for get number of record with current query parameter to know how many page
one time for request data for current page
I understand this BUT i suggest to improve it "somehow" with really new concept, doesnt require run query 2x.
This is not problem with small datasets,. But with Select with 4-5 joins really waste cpu time.
, im interested well, what is yours opinion here.
, found some migration script errors here:
has an extra "l" at the end of the dual on the SELECT register_migration_script line
The element, column and field have non-system IDs and will collide in an existing db.
The tests failed.
I changed Product Info to not load the count.
Tested Info product in GardenWorld
It doesn't know when is the last page.
Pushing the last button on the paging navigates to record 2147483646 (page 429496730)
If you push the next page button repeatedly it doesn't know when to stop.
new commit is cover this case.
when detect last page in cache or user enter out of page (include click last page button) will set exact page count
I also tested your commits attached to this issue. But info window is running almost every time method testCount from validateEndPage method. Why this can happen? Maybe I forgot to apply some commits from other tickets.
thanks . but i can't confirm your issue.
maybe i misunderstard your idea.
validateEndPage will run each time you come near end page or out of page
but testcount just run once time per each query.
example after you press query button and navigate by next, prev, last, first button. testcount just run one time.
Great , I like the result from this - that will speed up some info windows that are too big.