From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: PassDownLimitBound for ForeignScan/CustomScan |
Date: | 2016-09-13 17:20:31 |
Message-ID: | 14213.1473787231@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I agree that we should have some way for foreign data wrappers and
> custom scans and perhaps also other executor nodes to find out whether
> there's a known limit to the number of tuples that they might need to
> produce, but I wonder if we should be doing something more general
> than this.
I had the same feeling that this could stand to be considered more
generally, but had not had time to consider it in detail. The bound
passdown from Limit to Sort was never anything but a quick-and-dirty
private hack, and I'm not very comfortable with just exposing it to the
whole world without reconsidering the design.
> On a more practical level, I notice that you haven't adapted
> postgres_fdw or file_fdw to benefit from this new callback. It seems
> like postgres_fdw could benefit, because it could fetch only the
> required number of tuples if that happens to be a smaller number than
> the configured fetch_size.
I think we should insist on that, either in the base patch or a followup
patch, because you never know if a hook is actually convenient to use
until you try.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-09-13 17:55:52 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Previous Message | Robert Haas | 2016-09-13 17:17:20 | Re: DISABLE_PAGE_SKIPPING option for vacuumdb |