-
Notifications
You must be signed in to change notification settings - Fork 105
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
Optimize only one Schedule_a query #3939
Comments
Carlo recently asked about expression-based sorts which we may want to look into for improving Schedule A performance. |
Reviewed pgBadger output from 2019 September. The following one is one of the slow queries that involved fec_fitem_sched_a. This is a simple query but took avg of 8m1s to execute. SELECT count(*) AS count_1 FROM |
To simplified the tests, I only used one field (sub_id) to replace to lengthy list of selection. The drill down from pgBadger, the top 3 example from this queries use the combination of NY/NEW YORK, explain analyze When tested in STG database at a low traffic time. It actually took 29 minutes to run, with following execution plan: |
As a comparison, MD/POTOMAC combination is also tested. It only took 1 min 08 sec to execute, with all other condition the same: |
Both execution reveals that even with the same parameters input, with different cycles, database optimizer choose slightly different execution plan, depending on the size of the partitioned table and the data distribution. And with the same cycle partition table, different input parameters would resulted in different execution plan. |
To further simplified the testing condition, only 2019_2020 partition is demonstrated: "MA";"SOMERVILLE";489036;2.4427933908571326 |
"Bitmap Heap Scan on fec_fitem_sched_a_2019_2020 (cost=78764.27..193026.87 rows=29676 width=12) (actual time=8089.746..121598.635 rows=418497 loops=1)" |
"Bitmap Heap Scan on fec_fitem_sched_a_2019_2020 (cost=101.04..8672.32 rows=49 width=12) (actual time=3.168..21.151 rows=12421 loops=1)" Both columns contbr_city, contbr_st are indexed. depends on the input parameters, optimizer choose at least one of the indexes is used, as expected. |
Also considered if work_mem limit the speed. Expression-based index is not relevant for this query. |
@hcaofec had reviewed the comments listed above. We agreed we can close this ticket. |
Look at Rohan's research here:
#3739
#3697
Completion criteria:
The text was updated successfully, but these errors were encountered: