From: | Frank Millman <frank(at)chagford(dot)com> |
---|---|
To: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: SELECT is faster on SQL Server |
Date: | 2021-03-19 10:58:10 |
Message-ID: | 5a6f07d7-1d0f-f685-6743-d4dbc1730177@chagford.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2021-03-19 12:00 PM, Pavel Stehule wrote:
>
> In this query the most slow operation is query planning. You try to do
> tests on almost empty tables. This has no practical sense. You should
> test queries on tables with size similar to production size.
>
Sorry about that. I hope this one is better. Same query, different data set.
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------
Merge Left Join (cost=1401.00..1401.12 rows=1 width=132) (actual
time=3.595..3.611 rows=5 loops=1)
Merge Cond: (a.source_code_id = a_1.source_code_id)
-> GroupAggregate (cost=673.16..673.18 rows=1 width=36) (actual
time=1.101..1.108 rows=5 loops=1)
Group Key: a.source_code_id
-> Sort (cost=673.16..673.16 rows=1 width=12) (actual
time=1.092..1.093 rows=5 loops=1)
Sort Key: a.source_code_id
Sort Method: quicksort Memory: 25kB
-> Subquery Scan on a (cost=670.67..673.15 rows=1
width=12) (actual time=1.008..1.086 rows=5 loops=1)
Filter: (a.row_num = 1)
Rows Removed by Filter: 59
-> WindowAgg (cost=670.67..672.37 rows=62
width=36) (actual time=1.006..1.076 rows=64 loops=1)
-> Sort (cost=670.67..670.82 rows=62
width=28) (actual time=0.996..1.004 rows=64 loops=1)
Sort Key: ar_totals.location_row_id,
ar_totals.function_row_id, ar_totals.source_code_id, ar_totals.tran_date
DESC
Sort Method: quicksort Memory: 30kB
-> Seq Scan on ar_totals
(cost=0.00..668.82 rows=62 width=28) (actual time=0.012..0.933 rows=64
loops=1)
Filter: ((tran_date <=
'2015-04-30'::date) AND (deleted_id = 0) AND (ledger_row_id = 1))
Rows Removed by Filter: 840
-> GroupAggregate (cost=727.85..727.89 rows=2 width=36) (actual
time=2.490..2.495 rows=5 loops=1)
Group Key: a_1.source_code_id
-> Sort (cost=727.85..727.85 rows=3 width=12) (actual
time=2.485..2.485 rows=5 loops=1)
Sort Key: a_1.source_code_id
Sort Method: quicksort Memory: 25kB
-> Subquery Scan on a_1 (cost=700.70..727.82 rows=3
width=12) (actual time=1.684..2.479 rows=5 loops=1)
Filter: (a_1.row_num = 1)
Rows Removed by Filter: 674
-> WindowAgg (cost=700.70..719.35 rows=678
width=36) (actual time=1.682..2.397 rows=679 loops=1)
-> Sort (cost=700.70..702.40 rows=678
width=28) (actual time=1.676..1.758 rows=679 loops=1)
Sort Key: ar_totals_1.location_row_id,
ar_totals_1.function_row_id, ar_totals_1.source_code_id,
ar_totals_1.tran_date DESC
Sort Method: quicksort Memory: 78kB
-> Seq Scan on ar_totals ar_totals_1
(cost=0.00..668.82 rows=678 width=28) (actual time=0.007..0.836 rows=679
loops=1)
Filter: ((tran_date <
'2015-09-01'::date) AND (deleted_id = 0) AND (ledger_row_id = 1))
Rows Removed by Filter: 225
Planning Time: 0.496 ms
Execution Time: 3.695 ms
(34 rows)
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2021-03-19 11:04:38 | Re: SELECT is faster on SQL Server |
Previous Message | Pavel Stehule | 2021-03-19 10:00:32 | Re: SELECT is faster on SQL Server |