Re: ERROR: ORDER/GROUP BY expression not found in targetlist - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Date
Msg-id CA+TgmobbLEciSHq0O5EWYEKne58pqwQS4b4QNzF0Gks9af4xkA@mail.gmail.com
Whole thread Raw
In response to Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila@enterprisedb.com> writes:
>> It is slightly tricky to write a reproducible parallel-query test, but
>> point taken and I think we should try to have a test unless such a test is
>> really time consuming.
>
> BTW, decent regression tests could be written without the need to create
> enormous tables if the minimum rel size in create_plain_partial_paths()
> could be configured to something less than 1000 blocks.  I think it's
> fairly crazy that that arbitrary constant is hard-wired anyway.  Should
> we make it a GUC?

That was proposed before, and I didn't do it mostly because I couldn't
think of a name for it that didn't sound unbelievably corny.  Also,
the whole way that algorithm works is kind of a hack and probably
needs to be overhauled entirely in some future release.  I'm worried
about having the words "backward compatibility" thrown in my face when
it's time to improve this logic.  But aside from those two issues I'm
OK with exposing a knob.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: parallel workers and client encoding
Next
From: Robert Haas
Date:
Subject: Re: proposal: integration bloat tables (indexes) to core