Re: Why not install pgstattuple by default? - Mailing list pgsql-hackers

On Fri, May 6, 2011 at 1:32 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Fri, May 6, 2011 at 18:22, Euler Taveira de Oliveira
> <euler@timbira.com> wrote:
>> Em 06-05-2011 05:06, Magnus Hagander escreveu:
>>>
>>> On Fri, May 6, 2011 at 00:34, Josh Berkus<josh.berkus@pgexperts.com>
>>>  wrote:
>>>>
>>>> Hackers,
>>>>
>>>> I've run into a couple of occasions lately where I really wanted
>>>> pgstattuple on a production server in order to check table/index bloat.
>>>>  However, in the production environment at a large site installing a
>>>> contrib module can involve a process which takes days or weeks.
>>>
>> I already faced that problem too.
>>
>>>  From 9.1, it'll be a simple CREATE EXTENSION command - so much of the
>>> problem goes away. Well. It doesn't go away, but it gets a lot more
>>> neatly swept under the rug.
>>>
>> That's half of the history. Admin needs to install postgresql-contrib
>> package. Sometimes it takes too much time to convince clients that some
>> additional supplied modules are useful for them.
>>
>> Now that we have extensions, why not build and package the contrib modules
>> by default? 'make world' is not the answer. There is not an option for
>> "install all pieces of software". Let's install pg+contrib and leave only
>> 'CREATE EXTENSION foo' for the admins.
>
> That's mostly an issue to be solved by the packagers. Some contrib
> modules add dependencies, but those that don't could easily be
> packaged in the main server package.

It seems to me that there's something of a "packaging policy" question to this.

A long time ago, on a pre-buildfarm planet, far, far away, it was
pretty uncertain what contrib modules could be hoped to run on what
platform.

At Afilias, we used to have to be *really* picky, because the subset
that ran on Solaris and AIX were not even close to all of them.
pgstattuples *was* one that the DBAs always wanted, but what would
compile was alway hit-and-miss.

Once we got AIX running a buildfarm node, that led to getting *ALL* of
contrib working there, and I'm pretty sure that similar happened with
other platforms at around the same time (I'm thinking this was 7.4,
but it might have been 8.0)

Be that all as it may, there has been a "sea change", where we have
moved from "sporadic usability of contrib" to it being *continually*
tested on *all* buildfarm platforms, which certainly adds to the
confidence level.

But people are evidently still setting packaging policies based on how
things were back in 7.3, even though that perhaps isn't necessary
anymore.

Certainly it's not a huge amount of code; less than 2MB these days.
-> % wc `dpkg -L postgresql-contrib-9.0` | tail -1 15952   67555 1770987 total

I'm getting "paper cuts" quite a bit these days over the differences
between what different packaging systems decide to install.  The one
*I* get notably bit on, of late, is that I have written code that
expects to have pg_config to do some degree of self-discovery, only to
find production folk complaining that they only have "psql" available
in their environment.

I don't expect the extension system to help with any of this, since if
"production folk" try to install minimal sets of packages, they're
liable to consciously exclude extension support.  The "improvement"
would come from drawing contrib a bit closer to core, and encouraging
packagers (dpkg, rpm, ports) to fold contrib into "base" rather than
separating it.  I'm sure that would get some pushback, though.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"