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
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 |