Re: count(*), EXISTS, indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
Cc: Itai Zukerman <zukerman(at)math-hat(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: count(*), EXISTS, indexes
Date: 2003-04-12 00:00:06
Message-ID: 14783.1050105606@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Your query problem is that basically you have custom operators which the
> planner doesn't know how to evaluate the return results on correctly. This
> is a radically different situation from how you presented it in your first
> posting.

> This explains why the planner thinks that the exists clause will return
> 255,000 rows instead of the handful it actually does return. I'd suggest
> re-building the query in several different syntaxes, until you find the one
> the planner gets right.

Or more likely to work: build some custom selectivity estimation
functions to attach to the custom operators.

> Or build your own custom index types to take advantage of your custom
> operators. B-tree indexes are optimized for =, LIKE, <, and > queries; I
> don't think they know what to do with "~<="

They certainly don't. Possibly GIST could be taught what to do with
such things, but it won't happen by magic.

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Itai Zukerman 2003-04-12 04:01:49 Re: count(*), EXISTS, indexes
Previous Message Josh Berkus 2003-04-11 22:36:23 Re: count(*), EXISTS, indexes