Tom Lane wrote:
"Atul Deopujari" <[EMAIL PROTECTED]> writes:
Yes, letting the planner make its own decision would seem best (in
accordance with what we do for different join paths). But for large IN
lists, a substantial part of the planner is spent in estimating the
se
Hi,
Tom Lane wrote:
"Atul Deopujari" <[EMAIL PROTECTED]> writes:
Hi,
Tom Lane wrote:
That's the least of the problems. We really ought to convert such cases
into an IN (VALUES(...)) type of query, since often repeated indexscans
aren't the best implementation.
Hi,
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararray
Hi,
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararray
