Created
December 26, 2022 09:26
-
-
Save v-kolesnikov/316c1911f2ea2fc25cd012721d56559c to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
opts[:max_dataset_size] | |
It is a very important constant that provides a useful performance optimization. | |
For example we have N records in `users` table and want to show that number | |
under the corresponding table on `/users` page. It would be quite fast for DB | |
to count some tausands records and return that value back to the application. | |
But in case of 1M records the same task will load the DB server significantly | |
and without the relevant reason. There is no difference for web-app purposes | |
whether we have 1M or 1M+1 records in the DB . | |
And here `max_dataset_size` helps us. | |
Instead of counting the entire table as: | |
ds = User.dataset | |
ds.count | |
SELECT count(*) from users; | |
=> Counting 1M records ... | |
we count items in a limited dataset: | |
ds = User.dataset.limit(10000) | |
ds.count | |
SELECT count(*) FROM (SELECT * from users LIMIT 10000) | |
=> <= 10000 | |
Then we can compare returned value with ds.pagination_record_count | |
that always be <=10000 since ds is limited with that value. | |
If count is lower than max_dataset_size - we know the exactly count of | |
records. Otherwise we are sure there are more than 10000 items. | |
Finally this option serve for fast UI and better user experience. | |
In real life there is hardly a case where web ui should operate with | |
large dataset with 10k+ records. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment