Re: Thoughts on statistics for continuously advancing columns

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Thoughts on statistics for continuously advancing columns
Дата
Msg-id 18031.1262189805@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Thoughts on statistics for continuously advancing columns  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Thoughts on statistics for continuously advancing columns  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Thoughts on statistics for continuously advancing columns  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Thoughts on statistics for continuously advancing columns  (Csaba Nagy <nagy@ecircle-ag.com>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't have a better idea at the moment :-(
> It's been a while since I've been bitten by this issue -- the last
> time was under Sybase.  The Sybase suggestion was to either add
> "dummy rows" [YUCK!] to set the extreme bounds or to "lie to the
> optimizer" by fudging the statistics after each generation.  Perhaps
> we could do better by adding columns for high and low bounds to
> pg_statistic.  These would not be set by ANALYZE, but
> user-modifiable to cover exactly this problem?  NULL would mean
> current behavior?

Well, the problem Josh has got is exactly that a constant high bound
doesn't work.

What I'm wondering about is why he finds that re-running ANALYZE
isn't an acceptable solution.  It's supposed to be a reasonably
cheap thing to do.

I think the cleanest solution to this would be to make ANALYZE
cheaper, perhaps by finding some way for it to work incrementally.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: krb_server_keyfile setting doesn't work on Windows
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: krb_server_keyfile setting doesn't work on Windows