From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, pghackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Vik Fearing <vik(at)postgresfriends(dot)org> |
Subject: | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Date: | 2023-01-28 09:01:35 |
Message-ID: | CAFBsxsEWGGNACeNDLPd_q4xqFCP_W5g8_pbUsdkUMANVbyDxUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 28, 2023 at 3:21 PM Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com>
wrote:
>
> > On 26/01/23 07:40, David Rowley wrote:
> > We might want to look at 1) Expanding
> > on what 69749243 did and considering if we want sort specialisations
> > that are specifically for 1 column and another set for multi-columns.
> > The multi-column ones don't need to re-compare key[0] again. 2)
> > Sorting in smaller batches that better fit into CPU cache. Both of
> > these ideas would require a large amount of testing and discussion.
> > For #1 we're considering other specialisations, for example NOT NULL,
> > and we don't want to explode the number of specialisations we have to
> > compile into the binary.
>
> Yes, 1 & 2 needs to be addressed before going ahead with this patch.
> Do we any have ongoing thread with #1 and #2?
I recently brought up this older thread (mostly about #1), partly because
of the issues discovered above, and partly because I hope to make progress
on it before feature freeze (likely early April):
--
John Naylor
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ankit Kumar Pandey | 2023-01-28 10:49:59 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Previous Message | Ankit Kumar Pandey | 2023-01-28 08:21:09 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |