Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan - Mailing list pgsql-hackers

From Tiago Antão
Subject Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Date
Msg-id Pine.LNX.4.21.0008231543340.4273-100000@eros.si.fct.unl.pt
Whole thread Raw
In response to Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Hi!

On Wed, 23 Aug 2000, Tom Lane wrote:

> Yes, we know about that one.  We have stats about the most common value
> in a column, but no information about how the less-common values are
> distributed.  We definitely need stats about several top values not just
> one, because this phenomenon of a badly skewed distribution is pretty
> common.

 An end-biased histogram has stats on top values and also on the least
frequent values. So if a there is a selection on a value that is well
bellow average, the selectivity estimation will be more acurate. On some
research papers I've read, it's refered that this is a better approach
than equi-width histograms (which are said to be the "industry" standard).
 I not sure whether to use a table or a array attribute on pg_stat for
the histogram, the problem is what could be expected from the size of the
attribute (being a text). I'm very affraid of the cost of going through
several tuples on a table (pg_histogram?) during the optimization phase.
 One other idea would be to only have better statistics for special
attributes requested by the user... something like "analyze special
table(column)".

Best Regards,
Tiago




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem with insert
Next
From: The Hermit Hacker
Date:
Subject: [7.0.2] problems with spinlock under FreeBSD?