| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | lapham(at)jandr(dot)org |
| Cc: | Paul Tillotson <pntil(at)shentel(dot)net>, Kevin Murphy <murphy(at)genome(dot)chop(dot)edu>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: performance of IN (subquery) |
| Date: | 2004-08-27 13:57:39 |
| Message-ID: | 10223.1093615059@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Jon Lapham <lapham(at)jandr(dot)org> writes:
> Tom Lane wrote:
>> I've thought about this before. One simple trick would be to get rid
>> of the current pg_class reltuples/relpages fields in favor of a
>> tuples-per-page estimate, which could be multiplied by
>> RelationGetNumberOfBlocks() during planning.
> My first reaction is to wonder if this would give performance exactly
> equal to running a true ANALYZE in every situation?
No, this is quite orthogonal to ANALYZE (and several orders of magnitude
cheaper...) It would fix a lot of the simpler cases, though, since the
first-order effects like table size would be right.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Paul Tillotson | 2004-08-27 14:07:30 | Re: performance of IN (subquery) |
| Previous Message | Santiago Cassina | 2004-08-27 13:47:34 | Audit |