| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| Cc: | Arjen van der Meijden <acmmailing(at)vulcanus(dot)its(dot)tudelft(dot)nl>, pgsql-hackers(at)postgreSQL(dot)org, pgsql-performance(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Recognizing range constraints (was Re: Plan for relatively simple query seems to be very inefficient) |
| Date: | 2005-04-06 22:35:10 |
| Message-ID: | 6594.1112826910@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> On Wed, Apr 06, 2005 at 06:09:37PM -0400, Tom Lane wrote:
>> Can anyone suggest a more general rule? Do we need for example to
>> consider whether the relation membership is the same in two clauses
>> that might be opposite sides of a range restriction? It seems like
>>
>> a.x > b.y AND a.x < b.z
> In a case like this, you could actually look at the data in b and see
> what the average range size is.
Not with the current statistics --- you'd need some kind of cross-column
statistics involving both y and z. (That is, I doubt it would be
helpful to estimate the average range width by taking the difference of
independently-calculated mean values of y and z ...) But yeah, in
principle it would be possible to make a non-default estimate.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John A Meinel | 2005-04-06 22:54:07 | Re: [HACKERS] Recognizing range constraints (was Re: Plan |
| Previous Message | Jim C. Nasby | 2005-04-06 22:25:36 | Re: [HACKERS] Recognizing range constraints (was Re: Plan for relatively simple query seems to be very inefficient) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2005-04-06 22:41:02 | Re: How to improve db performance with $7K? |
| Previous Message | Jim C. Nasby | 2005-04-06 22:25:36 | Re: [HACKERS] Recognizing range constraints (was Re: Plan for relatively simple query seems to be very inefficient) |