Re: Question about (probably wrong) index scan cost for conditional indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Question about (probably wrong) index scan cost for conditional indexes
Date: 2012-01-30 01:02:28
Message-ID: 22022.1327885348@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> writes:
> Seems previous test case not clear demonstrate the problem which i have
> stuck with.
> Now much better and close to reality test case:

AFAICT, these behaviors all boil down to the fact that contrib/intarray
doesn't provide a real cost estimator for its && operator. It's using
the "contsel" stub function, which provides a fixed selectivity of
0.001. In your test case, with 1000000 rows in the table, the estimate
for the number of rows satisfying "sections && '{2}'" thus comes out to
exactly 1000. Unfortunately, the true number is around 100000, and it's
that discrepancy that is leading to all of these bad cost estimates.

What I'd like to see done about this is for somebody to adapt the
work Jan Urbanski did on tsvector stats collection and estimation
so that it works for the anyarray operators. It's a bit too late
to imagine that that'll get done for 9.2, but maybe for 9.3.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2012-01-30 01:15:13 Re: MS Access easier with PostgreSQL or MySQL?
Previous Message Adam Rich 2012-01-30 00:37:29 Re: Interval ordering