Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan

Поиск
Список
Период
Сортировка
От Tiago Antão
Тема Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Дата
Msg-id Pine.LNX.4.21.0008231543340.4273-100000@eros.si.fct.unl.pt
обсуждение исходный текст
Ответ на 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
Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Problem with insert
Следующее
От: The Hermit Hacker
Дата:
Сообщение: [7.0.2] problems with spinlock under FreeBSD?