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
|
Список | 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 по дате отправления: