Re: ANALYZE versus expression indexes with nondefault opckeytype

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: ANALYZE versus expression indexes with nondefault opckeytype
Дата
Msg-id AANLkTinXGDjNne3=msbBWojVFV=fMJ_g4p=y_+SVRf2d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ANALYZE versus expression indexes with nondefault opckeytype  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: ANALYZE versus expression indexes with nondefault opckeytype  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, Jul 31, 2010 at 9:16 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Kevin Grittner (Kevin.Grittner@wicourts.gov) wrote:
>> Robert Haas  07/31/10 12:33 PM >>>
>> > Tom Lane  wrote:
>> >> Failing to store stats isn't a bug?
>> >
>> > Well, it kind of sounds more like you're removing a known
>> > limitation than fixing a bug.
>>
>> It's operating as designed and documented.  There is room for
>> enhancement, but the only thing which could possibly justify this as
>> 9.0 material is if there was a demonstrated performance regression in
>> 9.0 for which this was the safest cure.
>
> I have to disagree with this, to be honest.  The fact that we've
> documented what is completely unexpected and frustrating behaviour
> doesn't mean we get to say it's not a bug.  Not collecting stats, at
> all, is a pretty bad bug, in my view.

I guess I'd appreciate it if someone could explain in more detail in
what cases we fail to collect stats.  Do we have a typanalyze function
here that can't possibly work for anything, ever?  Or is it just some
subset of the cases?

(Apologies if this has been discussed on the original thread; I was
unable to find it in the archives.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: More fun with GIN lossy-page pointers
Следующее
От: Robert Haas
Дата:
Сообщение: Re: review: psql: edit function, show function commands patch