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 scalararraysel(), which in turn estimates the selectivity of
*each* array e
Neil Conway wrote:
Clearly, the current approach is fine when the array is small -- perhaps
for arrays above a certain number of elements, we could switch to
randomly sampling array elements, estimating their selectivities, and
then using that information to infer the estimated selectivity of th
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 scalararraysel(), which in
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Thursday, May 10, 2007 11:53 AM
> To: Neil Conway
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Planning large IN lists
>
> Ne
Is this a TODO?
---
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. I
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
"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.
>>
> I thought of giving this a shot and wh
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.
I thought of giving this a shot
"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
> selectivity of the ScalarArrayExpr by
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
selectivity of the Scalar
Added to TODO:
* Consider using a hash for joining to a large IN (VALUES ...) list
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php
---
Atul Deopujari wrote:
> Hi,
>
> Tom Lane wrote:
> > Neil Conway <
12 matches
Mail list logo
