Re: BETWEEN optimizer problems with single-value

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org, Andreas Kretschmer <akretschmer(at)spamfence(dot)net>
Subject: Re: BETWEEN optimizer problems with single-value
Date: 2006-03-16 15:57:01
Message-ID: 17043.1142524621@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Trying to get the information in the wrong place would be very
> expensive, I agree. But preparing that information when we have access
> to it and passing it through the plan would be much cheaper.

Where would that be?

> The operator and the opclass are only connected via an index access
> method, but for a particular index each column has only one opclass.

If you're proposing making clauselist_selectivity depend on what indexes
exist, I think that's very much the wrong approach. In the first place,
it still has to give usable answers for unindexed columns, and in the
second place there might be multiple indexes with different opclasses
for the same column, so the ambiguity problem still exists.

I have been wondering if we shouldn't add some more indexes on pg_amop
or something to make it easier to do this sort of lookup --- we
definitely seem to be finding multiple reasons to want to look up
which opclasses contain a given operator.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-03-16 16:06:54 Re: [HACKERS] Bug report form: locale/encoding
Previous Message Magnus Hagander 2006-03-16 15:44:25 Re: [HACKERS] Bug report form: locale/encoding

Browse pgsql-performance by date

  From Date Subject
Next Message Guillaume Smet 2006-03-16 16:05:38 Re: PostgreSQL and Xeon MP
Previous Message Sven Geisler 2006-03-16 15:20:31 Re: PostgreSQL and Xeon MP