Re: contrib/pg_stat_statements

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/pg_stat_statements
Date: 2008-10-20 12:43:50
Message-ID: 48FC7D06.1090800@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ITAGAKI Takahiro wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
>>> I'd like to submit pg_stat_statements contrib module
>> Sounds very good, but why contrib and not along with the rest of the
>> stats stuff in the main backend (with an on/off switch if the overhead
>> is high)?
>
> That's because it could be done as a contrib module ;-)
> (Yeah! Postgres is a very extensible database!)

It can also go as a pgfoundry project, no? ;-)

Given that making it a contrib module instead of core will significantly
decrease the exposure, I personally consider that a bad thing..

> I'm not sure what should be in the main and what should not.
> Why is pg_freespacemap still in contrib?

I don't know, why is it? :-)

> I think the module is not mature yet and users will want to
> modify it to their satisfaction. It will be easier if the
> module is separated from the core codes. (The same can be
> said for contrib/auto_explan, which is my other proposal.)

Yes, that is a reasonable argument for keeping it in contrib. Or perhaps
even better, on pgFoundry until it is ready.

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-20 12:46:07 Re: SQL:2008 LIMIT/OFFSET
Previous Message Simon Riggs 2008-10-20 11:07:43 Index use during Hot Standby