I wrote:
> Have two memtuple arrays, one for first sortkey null and one for first
sortkey non-null:
Hacking on this has gotten only as far as the "compiles but segfaults"
stage, but I wanted to note an idea that occurred to me:
Internal qsort doesn't need the srctape member, and removing both tha
I wrote:
> On Thu, Jan 26, 2023 at 7:15 PM David Rowley wrote:
> > I think the slower sorts I found in [2] could also be partially caused
> > by the current sort specialisation comparators re-comparing the
> > leading column during a tie-break. I've not gotten around to disabling
> > the sort spe
On Thu, Jan 26, 2023 at 7:15 PM David Rowley wrote:
>
> On Thu, 26 Jan 2023 at 23:29, John Naylor
wrote:
> > Coming back to this, I wanted to sketch out this idea in a bit more
detail.
> >
> > Have two memtuple arrays, one for first sortkey null and one for first
sortkey non-null:
> > - Qsort the
On Thu, 26 Jan 2023 at 23:29, John Naylor wrote:
> Coming back to this, I wanted to sketch out this idea in a bit more detail.
>
> Have two memtuple arrays, one for first sortkey null and one for first
> sortkey non-null:
> - Qsort the non-null array, including whatever specialization is availabl
On Thu, Jan 26, 2023 at 6:14 PM Pavel Borisov
wrote:
> > - Only if there is more than one sort key, qsort the null array.
Ideally at some point we would have a method of ignoring the first sortkey
(this is an existing opportunity that applies elsewhere as well).
> Should we need to sort by the s
Hi, John!
Generally, I like the separation of non-null values before sorting and
would like to join as a reviewer when we come to patch. I have only a
small question:
> - Only if there is more than one sort key, qsort the null array. Ideally at
> some point we would have a method of ignoring the
On Tue, Aug 23, 2022 at 1:13 PM John Naylor
wrote:
>
> On Tue, Aug 23, 2022 at 11:24 AM David Rowley
wrote:
> >
> > On Tue, 23 Aug 2022 at 15:22, John Naylor
wrote:
> > > Did you happen to see
> > >
> > >
https://www.postgresql.org/message-id/CAFBsxsFhq8VUSkUL5YO17cFXbCPwtbbxBu%2Bd9MFrrsssfDXm3Q
On Tue, Aug 23, 2022 at 11:24 AM David Rowley wrote:
>
> On Tue, 23 Aug 2022 at 15:22, John Naylor
> wrote:
> > Did you happen to see
> >
> > https://www.postgresql.org/message-id/CAFBsxsFhq8VUSkUL5YO17cFXbCPwtbbxBu%2Bd9MFrrsssfDXm3Q%40mail.gmail.com
>
> I missed that. It looks like a much more
On Tue, 23 Aug 2022 at 15:22, John Naylor wrote:
> Did you happen to see
>
> https://www.postgresql.org/message-id/CAFBsxsFhq8VUSkUL5YO17cFXbCPwtbbxBu%2Bd9MFrrsssfDXm3Q%40mail.gmail.com
I missed that. It looks like a much more promising idea than what I
came up with. I've not looked at your code
On Tue, Aug 23, 2022 at 9:18 AM David Rowley wrote:
>
> I have the following dimensions in mind for consideration:
>
> 1. Specialisations to handle sorting of non-null datums (eliminates
> checking for nulls in the comparison function)
> 2. Specialisations to handle single column sorts (eliminates
Hi,
(Background: 697492434 added 3 new sort functions to remove the
indirect function calls for the comparator function. This sped up
sorting for various of our built-in data types.)
There was a bit of unfinished discussion around exactly how far to
take these specialisations for PG15. We could
11 matches
Mail list logo
