Re: Draft LIMIT pushdown to Append and MergeAppend patch - Mailing list pgsql-hackers

From Michał Kłeczek
Subject Re: Draft LIMIT pushdown to Append and MergeAppend patch
Date
Msg-id 6235B14D-455C-4424-9B26-F39F4EB55E31@kleczek.org
Whole thread Raw
In response to Re: Draft LIMIT pushdown to Append and MergeAppend patch  (Andy Fan <zhihui.fan1213@gmail.com>)
Responses Re: Draft LIMIT pushdown to Append and MergeAppend patch
List pgsql-hackers
Thanks for the feedback.

On 8 Oct 2023, at 03:33, Andy Fan <zhihui.fan1213@gmail.com> wrote:



On Sun, Oct 8, 2023 at 5:04 AM Michał Kłeczek <michal@kleczek.org> wrote:
Hi All,

Attached is a second version of the patch.

The goal is to:
1. Apply LIMIT as early as possible - especially to apply LIMIT in partition scans

For the patches for performance improvement,  it is better to provide
an example to show how much benefits we can get.  As for this case,
I'm doubtful it can work as an improvement. 

2. Enable LIMIT pushdown for FDW partitions.

The same as above,  some testing is helpful. 

The idea came up from this e-mail thread from 2019:


While obviously permofmance testing is needed to confirm any real improvements
I now (after your feedback) have second thoughts if it is worth pursuing at all.

Could you elaborate a little why you think it won’t work as an improvement?
Is it because in practice LIMIT _is_ pushed down already during execution?
From what I understand postgres_fdw does indeed fetch on demand.
OTOH pushing down LIMIT is considered an improvement (as witnessed in the postgres_fdw code itself after d50d172e51)

Care to provide some more information?

Thanks,

--
Michal

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pg_upgrade --copy-file-range
Next
From: Richard Guo
Date:
Subject: Re: pg16: XX000: could not find pathkey item to sort