Re: Allow ordered partition scans in more cases - Mailing list pgsql-hackers

From David Rowley
Subject Re: Allow ordered partition scans in more cases
Date
Msg-id CAApHDvqWRkTa14yYTRmVYdELwz7XEdg_kqQSqQy4ZxrVbVygKA@mail.gmail.com
Whole thread Raw
In response to Re: Allow ordered partition scans in more cases  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Sat, 4 Mar 2023 at 00:56, David Rowley <dgrowleyml@gmail.com> wrote:
> What's on my mind now is if turning 1 Sort into N Sorts is a
> particularly good idea from a work_mem standpoint. I see that we don't
> do tuplesort_end() until executor shutdown, so that would mean that we
> could end up using 1 x work_mem per Sort node.  I idly wondered if we
> couldn't do tuplesort_end() after spitting out the final tuple when
> EXEC_FLAG_REWIND is not set, but that would still mean we could use N
> work_mems when EXEC_FLAG_REWIND *is* set. We only really have
> visibility of that during execution too, so can't really make a
> decision at plan time based on that.

Because of the above, I'm not planning on pursuing this patch any
further.  We can maybe revisit this if we come up with better ways to
manage the number of work_mems a plan can have in the future. As of
now, I'm a little too worried that this patch will end up consuming
too many work_mems by adding a Sort node per partition.

I'll mark this as withdrawn.

David



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Stampede of the JIT compilers
Next
From: Joe Conway
Date:
Subject: Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG