| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | Luc Vlaming <luc(at)swarm64(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: "could not find pathkey item to sort" for TPC-DS queries 94-96 |
| Date: | 2021-04-15 20:18:34 |
| Message-ID: | d0097e39-b4fb-effd-5701-dcbe4f2353df@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/15/21 2:21 AM, Robert Haas wrote:
> On Wed, Apr 14, 2021 at 8:20 PM James Coleman <jtc331(at)gmail(dot)com> wrote:
>>> Hmm, could be. Although, the stack trace at issue doesn't seem to show
>>> a call to create_incrementalsort_plan().
>>
>> The changes to gather merge path generation made it possible to use
>> those paths in more cases for both incremental sort and regular sort,
>> so by "incremental sort" I read Tomas as saying "the patches that
>> brought in incremental sort" not specifically "incremental sort
>> itself".
>
> I agree. That's why I said "hmm, could be" even though the plan
> doesn't involve one.
>
Yeah, that's what I meant. The difference to pre-13 behavior is that we
now call generate_useful_gather_paths, which also considers adding extra
sort (unlike plain generate_gather_paths).
So now we can end up with "Gather Merge -> Sort" paths that would not be
considered before.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-04-15 21:29:01 | Re: SQL-standard function body |
| Previous Message | Justin Pryzby | 2021-04-15 19:24:50 | Re: ATTACH PARTITION locking documentation for DEFAULT partitions |