På fredag 17. juni 2016 kl. 08:14:39, skrev Amit Kapila <amit.kapil...@gmail.com
On Fri, Jun 17, 2016 at 11:39 AM, Andreas Joseph Krogh <andr...@visena.com 
<mailto:andr...@visena.com>> wrote: På torsdag 16. juni 2016 kl. 20:19:44, 
skrev Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>>:
Amit Kapila <amit.kap...@enterprisedb.com <mailto:amit.kap...@enterprisedb.com>
> writes:
 > On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane <t...@sss.pgh.pa.us 
<mailto:t...@sss.pgh.pa.us>> wrote:
 >> min_parallel_relation_size, or min_parallelizable_relation_size, or
 >> something like that?

 > You are right that such a variable will make it simpler to write tests for
 > parallel query.  I have implemented such a guc and choose to keep the name
 > as min_parallel_relation_size.

 Pushed with minor adjustments.  My first experiments with this say that
 we should have done this long ago:

 > One thing to note is that in function
 > create_plain_partial_paths(), curently it is using PG_INT32_MAX/3 for
 > parallel_threshold to check for overflow, I have changed it to INT_MAX/3 so
 > as to be consistent with guc.c.  I am not sure if it is advisable to use
 > PG_INT32_MAX in guc.c as other similar parameters use INT_MAX.

 I agree that using INT_MAX is more consistent with the code elsewhere in
 guc.c, and more correct given that we declare the variable in question
 as int not int32.  But you need to include <limits.h> to use INT_MAX ...

 regards, tom lane

As of 4c56f3269a84a81461cc53941e0eee02fc920ab6 I'm still getting it in one of 
my queries:
ORDER/GROUP BY expression not found in targetlist
I am working on preparing a patch to fix this issue.
Am I missing something?

 No, the fix is still not committed.

Ah, I thought Tom pushed a fix, but it apparently was another fix.
Thanks for fixing.
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com <mailto:andr...@visena.com>
www.visena.com <https://www.visena.com>


Reply via email to