From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Soni M <diptatapa(at)gmail(dot)com> |
Cc: | Postgres Bug <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Scanning all partition when more than 100 items in "where id in ()" clause |
Date: | 2018-07-26 22:04:01 |
Message-ID: | 19851.1532642641@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Soni M <diptatapa(at)gmail(dot)com> writes:
> Hello All, I think I found bug here. Postgres 9.6.9 on Red Hat Enterprise
> Linux Server release 7.5 (Maipo).
I think it's a consequence of the limitation in predtest.c that it won't
try to do predicate proofs using ScalarArrayOps with more than 100 array
entries:
/*
* Proof attempts involving large arrays in ScalarArrayOpExpr nodes are
* likely to require O(N^2) time, and more often than not fail anyway.
* So we set an arbitrary limit on the number of array elements that
* we will allow to be treated as an AND or OR clause.
* XXX is it worth exposing this as a GUC knob?
*/
#define MAX_SAOP_ARRAY_SIZE 100
Not a bug, but a tradeoff. You'd be unhappy if the planner spent longer
devising the plan than it saved to eliminate the extra partitions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-07-26 22:06:45 | Re: BUG #15301: Scanning all partition when more than 100 items in "where id in ()" clause |
Previous Message | Tom Lane | 2018-07-26 21:04:26 | Re: BUG #15300: "do you want the application "postgres" to accept incoming network connections" dialog box madness |