| From: | Alexander Kuzmenkov <akuzmenkov(at)timescale(dot)com> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Incorrect cost for MergeAppend |
| Date: | 2024-01-31 13:37:28 |
| Message-ID: | CALzhyqxwyDELXE2wjuwjTsT38Y0e9ycg25LvKMngQBng31Svug@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 31, 2024 at 1:33 PM Alexander Kuzmenkov
<akuzmenkov(at)timescale(dot)com> wrote:
> I'd be happy to see this backpatched. What kind of regressions are we
> worried about? I'd say partition-wise sort + merge should be faster
> than append + sort for reasonably sized tables. That's basically what
> tuplesort does inside. Moreso, this can enable index scans on
> partitions, which is an even better plan.
To put it another way, this change enables our usual cost model for
MergeAppend to work correctly in the presence of filters. I think we
can consider this model to be reasonably correct, and we don't
currently have major problems with MergeAppend being chosen instead of
Sort + Append in cases where it's suboptimal, right? So applying it
properly in case with filters is not likely to introduce problems.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2024-01-31 13:52:03 | Re: Incorrect cost for MergeAppend |
| Previous Message | Alvaro Herrera | 2024-01-31 13:26:28 | Re: Emitting JSON to file using COPY TO |