From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Guo <guofenglinux(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, David Rowley <dgrowleyml(at)gmail(dot)com>, "a(dot)rybakina" <a(dot)rybakina(at)postgrespro(dot)ru> |
Subject: | Re: POC: GROUP BY optimization |
Date: | 2024-05-21 09:01:19 |
Message-ID: | 282f19f0-cbae-4233-9344-07307c044696@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20/5/2024 15:54, jian he wrote:
> As mentioned previously,
> both A and B can use Incremental Sort, set_cheapest will choose the A
> instead of B,
> because A step generated path **first** satisfies increment sort.
Yeah, I agree with your analysis.
Looking into the cost_incremental_sort, I see that we have ten
group_tuples. This value doesn't depend on how many presorted keys (1 or
2) we use. This is caused by default estimation.
Given the current circumstances, it seems unlikely that we can make any
significant changes without introducing a new sort cost model that
accounts for the number of sorted columns.
--
regards,
Andrei Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Nazir Bilal Yavuz | 2024-05-21 09:14:43 | Re: zlib detection in Meson on Windows broken? |
Previous Message | Nazir Bilal Yavuz | 2024-05-21 08:18:34 | Re: CREATE DATABASE with filesystem cloning |