Thread: Any reasons to not move pgstattuple to core?
Hi, In my practice I quite often face the problem of bloated tables. I usually use pgstattuple to perform investigations. I also create a tool that uses UPDATEs based way to smoothly remove bloat (https://github.com/grayhemp/pgtoolkit), and it partially depends on pgstatuple too. To be more precise it gets much more effective with pgstattuple. Sometimes its installation leads to a headache, because it requires an approve from security and admins, it also a problem when I have a read-only access or no access to the database at all (eg. when consulting somebody by IM or phone). I think I am not the only person who faced these nuances. According to this I would like to know if it is possible to move pgstattuple to core? And if it is I would like to request this feature. Thank you. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray.ru@gmail.com
On Thu, Oct 3, 2013 at 5:37 PM, Sergey Konoplev <gray.ru@gmail.com> wrote: > In my practice I quite often face the problem of bloated tables. I > usually use pgstattuple to perform investigations. I also create a > tool that uses UPDATEs based way to smoothly remove bloat > (https://github.com/grayhemp/pgtoolkit), and it partially depends on > pgstatuple too. To be more precise it gets much more effective with > pgstattuple. > > Sometimes its installation leads to a headache, because it requires an > approve from security and admins, it also a problem when I have a > read-only access or no access to the database at all (eg. when > consulting somebody by IM or phone). I think I am not the only person > who faced these nuances. Well, this is a general problem with any extension - somebody might want it on a system on which the admin is unable or unwilling to install it. But we can't put every possible extension in core. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Well, this is a general problem with any extension - somebody might > want it on a system on which the admin is unable or unwilling to > install it. But we can't put every possible extension in core. The flip-side is that we could have made an awful lot of built-in things extensions, but for whatever reason chose not to. I'm not necessarily in favor of putting pgstattuple in core, but the question should be asked: Why should we do this here? In what way is pgstattuple like or not like the other things that are in core? -- Peter Geoghegan
On Thu, Oct 3, 2013 at 3:55 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> Well, this is a general problem with any extension - somebody might >> want it on a system on which the admin is unable or unwilling to >> install it. But we can't put every possible extension in core. > > The flip-side is that we could have made an awful lot of built-in > things extensions, but for whatever reason chose not to. I'm not > necessarily in favor of putting pgstattuple in core, but the question > should be asked: Why should we do this here? In what way is > pgstattuple like or not like the other things that are in core? I would highlight it as it became a kind of routine one. Also, sometimes it is required to solve problems, not to make new features, so it often can not wait. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray.ru@gmail.com
Sergey Konoplev escribió: > On Thu, Oct 3, 2013 at 3:55 PM, Peter Geoghegan <pg@heroku.com> wrote: > > On Thu, Oct 3, 2013 at 3:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: > >> Well, this is a general problem with any extension - somebody might > >> want it on a system on which the admin is unable or unwilling to > >> install it. But we can't put every possible extension in core. > > > > The flip-side is that we could have made an awful lot of built-in > > things extensions, but for whatever reason chose not to. I'm not > > necessarily in favor of putting pgstattuple in core, but the question > > should be asked: Why should we do this here? In what way is > > pgstattuple like or not like the other things that are in core? > > I would highlight it as it became a kind of routine one. Also, > sometimes it is required to solve problems, not to make new features, > so it often can not wait. Greg Smith made a list some months ago of contrib modules that were essential for forensics analysis and such. Weren't we going to do something special about those? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Oct 3, 2013 at 6:36 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Greg Smith made a list some months ago of contrib modules that were > essential for forensics analysis and such. Weren't we going to do > something special about those? It was more like two years ago. I do still think that that kind of effort makes a lot of sense. -- Peter Geoghegan
On Thu, Oct 3, 2013 at 10:01 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Thu, Oct 3, 2013 at 6:36 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> Greg Smith made a list some months ago of contrib modules that were >> essential for forensics analysis and such. Weren't we going to do >> something special about those? > > It was more like two years ago. I do still think that that kind of > effort makes a lot of sense. I think we were going to try to group the extensions into categories (debugging tools, demonstration code, data types, etc.) and maybe encourage packagers to put the debugging tools in the same OS package as the core server. But Tom was not supportive, and he was at the time the packager for Red Hat, so it didn't seem like we were going to get to far with it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Oct 4, 2013 at 6:44 AM, Robert Haas <robertmhaas@gmail.com> wrote: > I think we were going to try to group the extensions into categories > (debugging tools, demonstration code, data types, etc.) and maybe > encourage packagers to put the debugging tools in the same OS package > as the core server. I was thinking more about different extension tiers, grouping them by quality/usefulness. -- Peter Geoghegan
Robert Haas <robertmhaas@gmail.com> writes: > I think we were going to try to group the extensions into categories > (debugging tools, demonstration code, data types, etc.) and maybe > encourage packagers to put the debugging tools in the same OS package > as the core server. But Tom was not supportive, and he was at the > time the packager for Red Hat, so it didn't seem like we were going to > get to far with it. My understanding is that we wanted to promote some extensions as being "core extensions" and change the directory and documentation layout to encourage packagers to rethink they work. And my understanding of Tom's reaction is that he didn't believe the source directory layout has anything to do with the packaging problem, we should just document the extensions we want installed by default and packagers will know to follow us there. Still, *something* needs to be done here. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
[ back from vacation and slowly catching up on email ]
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I think we were going to try to group the extensions into categories
>> (debugging tools, demonstration code, data types, etc.) and maybe
>> encourage packagers to put the debugging tools in the same OS package
>> as the core server. But Tom was not supportive, and he was at the
>> time the packager for Red Hat, so it didn't seem like we were going to
>> get to far with it.
> My understanding is that we wanted to promote some extensions as being
> "core extensions" and change the directory and documentation layout to
> encourage packagers to rethink they work.
> And my understanding of Tom's reaction is that he didn't believe the
> source directory layout has anything to do with the packaging problem,
> we should just document the extensions we want installed by default and
> packagers will know to follow us there.
> Still, *something* needs to be done here.
Since people seemed to be mentioning my opinions in this thread,
I'll weigh in with a couple of thoughts:
1. I think Dimitri's summary of my opinion is okay as far as the general
topic goes: if we want packagers to favor certain contrib modules over
others, we should just tell them so. No need to complicate our own lives
by rearranging the source tree.
2. As far as pgstattuple in particular goes, I would not be at all
in favor of pushing it into core in its current form. It's an ugly
hodgepodge of functions that weren't too well designed to start with
and aren't even mutually consistent. We could take the opportunity
to redesign, perhaps, if we were going to put such functionality in
core --- but please let's not just push over what's there.
regards, tom lane