Re: [PATCH] Push limit to sort through a subquery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Douglas Doole <dougdoole(at)gmail(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Push limit to sort through a subquery
Date: 2017-08-25 14:46:43
Message-ID: 32422.1503672403@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm inclined to commit both of these after a little more testing and
> self-review, but let me know if anyone else wants to review first.

Attached is an updated version of the first patch, which I rebased
over 3f4c7917b, improved a bunch of the comments for, and fixed a
couple of obvious typos in. However, when I went to test it,
it blew up real good:

regression=# set parallel_setup_cost=0;
SET
regression=# set parallel_tuple_cost=0;
SET
regression=# set min_parallel_table_scan_size=0;
SET
regression=# set max_parallel_workers_per_gather=4;
SET
regression=# explain analyze select * from tenk1 order by fivethous limit 4;
ERROR: retrieved too many tuples in a bounded sort
CONTEXT: parallel worker

The cause is obvious: GatherMerge doesn't know about the contract that
it's not supposed to pull more than tuples_needed rows from an input after
promising not to do so. I am not convinced that it's worth adding the
logic that would be needed to make that happen, so my inclination is to
abandon this patch. But here it is if you want to push further.

regards, tom lane

Attachment Content-Type Size
push-down-bound-to-workers-2.patch text/x-diff 16.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-08-25 14:58:41 Re: [PATCH] Push limit to sort through a subquery
Previous Message Amit Kapila 2017-08-25 14:26:00 Re: [PATCH] Push limit to sort through a subquery