Skip site navigation (1) Skip section navigation (2)

Re: ANALYZE versus expression indexes with nondefaultopckeytype

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ANALYZE versus expression indexes with nondefaultopckeytype
Date: 2010-08-01 01:16:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Kevin Grittner (Kevin(dot)Grittner(at)wicourts(dot)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.  Stats are an important part of
the system which needs to work at least decently.  Perhaps before it was
pretty rare that we'd have the situation described (before we brought in
tsearch2), but it's not any longer and we need to support it as we would
the other types.  The only reason I'm against backpatching it to the
beginning is that it's either an ABI change or some rather grotty code,
and even then it wouldn't be hard to push me to accepting the grotty
code if we make the cleaner change for 9.0 and going forward, especially
as we have people in the wild being affected by it.

Certain other databases have done a very good job of documenting their
bugs and in some cases even calling them features.  I'd rather we not go
down that path.  I don't see the lack of stats collecting to be a simple



In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-08-01 01:35:51
Subject: Re: More fun with GIN lossy-page pointers
Previous:From: Robert HaasDate: 2010-08-01 01:11:53
Subject: Re: review patch: Distinguish between unique indexes and unique constraints

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group