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
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 |