Re: Collect frequency statistics for arrays - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Collect frequency statistics for arrays
Date
Msg-id 1330614477-sup-5978@alvh.no-ip.org
Whole thread Raw
In response to Re: Collect frequency statistics for arrays  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Collect frequency statistics for arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Excerpts from Robert Haas's message of jue mar 01 12:00:08 -0300 2012:
> On Wed, Feb 29, 2012 at 5:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> > No, just that we'd no longer have statistics relevant to that, and would
> > have to fall back on default selectivity assumptions.  Do you think that
> > such applications are so common as to justify bloating pg_statistic for
> > everybody that uses arrays?
>
> I confess I am nervous about ripping this out.  I am pretty sure we
> will get complaints about it.  Performance optimizations that benefit
> group A at the expense of group B are always iffy, and I'm not sure
> the case of using an array as a path indicator is as uncommon as you
> seem to think.

Maybe we should keep it as an option.  I do think it's quite uncommon,
but for those rare users, it'd be good to provide the capability while
not bloating everyone else's stat catalog.  The thing is, people using
arrays as path indicators and such are likely using relatively small
arrays; people storing real data are likely to store much bigger arrays.
Just a hunch though.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Collect frequency statistics for arrays
Next
From: Marko Kreen
Date:
Subject: Re: Speed dblink using alternate libpq tuple storage