| From: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: integration bloat tables (indexes) to core |
| Date: | 2016-06-16 20:31:02 |
| Message-ID: | 57630C86.6020403@2ndquadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16/06/16 20:31, Jim Nasby wrote:
> On 6/13/16 12:16 PM, Tom Lane wrote:
>> At the same time, I'm pretty suspicious of putting stuff like this in
>> core, because the expectations for cross-version compatibility go up
>> by orders of magnitude as soon as we do that.
>
> On a first go-round, I don't think we should add entire views, but
> rather functions that serve specific purposes. For table bloat that
> means a function that returns what the heap size should be based on
> pg_stats. For locking, it means providing information about which PID is
> blocking which PID. After that, most everything else is just window
> dressing.
We already have that second one: pg_blocking_pids(integer)
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-06-16 20:31:14 | Parallelized polymorphic aggs, and aggtype vs aggoutputtype |
| Previous Message | Pavel Stehule | 2016-06-16 19:10:41 | Re: proposal: integration bloat tables (indexes) to core |