On Mon, Jan 29, 2018 at 10:08:51AM +0900, Amit Langote wrote:
> On 2018/01/27 3:32, Robert Haas wrote:
>> If it has
>> either partitions or inheritance children, find_all_inheritors will
>> return them. Otherwise, I think it'll just return the input OID
>> itself. So I don't quite see, if we're g
On 2018/01/27 3:32, Robert Haas wrote:
> On Fri, Jan 26, 2018 at 7:45 AM, Michael Paquier
> wrote:
>> There could be value in having a version dedicated to inheritance trees
>> as well, true enough. As well as value in having something that shows
>> both. Still let's not forget that partition se
On Fri, Jan 26, 2018 at 7:45 AM, Michael Paquier
wrote:
> There could be value in having a version dedicated to inheritance trees
> as well, true enough. As well as value in having something that shows
> both. Still let's not forget that partition sets are structured so as
> the parents have no
On Fri, Jan 26, 2018 at 07:00:43PM +0900, Amit Langote wrote:
> I wonder what pg_partition_tree_tables() should return when passed a table
> that doesn't have partitions under it? Return a 1-member set containing
> itself?
Yes. A table alone is itself part of a partition set, so the result
shoul
On 2018/01/22 11:44, Michael Paquier wrote:
> On Sun, Jan 21, 2018 at 07:16:38PM +1300, David Rowley wrote:
>> On 20 January 2018 at 23:14, Michael Paquier
>> wrote:
>>> If pg_partition_tree_tables() uses the top of the partition as input,
>>> all the tree should show up. If you use a leaf, anyth
On Sun, Jan 21, 2018 at 07:16:38PM +1300, David Rowley wrote:
> On 20 January 2018 at 23:14, Michael Paquier
> wrote:
>> If pg_partition_tree_tables() uses the top of the partition as input,
>> all the tree should show up. If you use a leaf, anything under the leaf
>> should show up. If a leaf is
On 20 January 2018 at 23:14, Michael Paquier wrote:
> If pg_partition_tree_tables() uses the top of the partition as input,
> all the tree should show up. If you use a leaf, anything under the leaf
> should show up. If a leaf is defined and it has no underlying leaves,
> then only this outmost lea
On Fri, Jan 19, 2018 at 06:28:41PM +0900, Amit Langote wrote:
> Do you mean pg_partition_tree(regclass), that returns all partitions in
> the partition tree whose root is passed as the parameter?
>
> Perhaps, like the following (roughly implemented in the attached)?
>
> select pg_partition_root(
Thanks for taking a look.
On 2018/01/19 14:39, Michael Paquier wrote:
> On Thu, Jan 18, 2018 at 06:54:18PM +0900, Amit Langote wrote:
>> I think having pg_partition_root() and pg_partition_parent() will give
>> users enough to get useful views as follows:
>
> So... pg_partition_root() gives you a
On Thu, Jan 18, 2018 at 06:54:18PM +0900, Amit Langote wrote:
> I think having pg_partition_root() and pg_partition_parent() will give
> users enough to get useful views as follows:
So... pg_partition_root() gives you access to the highest relation in
the hierarchy, and pg_partition_parent() gives
On 2018/01/02 22:45, Peter Eisentraut wrote:
> On 12/28/17 16:24, David Rowley wrote:
>>> select pg_partition_root(c.oid), c.relname, pg_table_size(c.oid)
>>> from pg_class c
>>> order by 1
>>>
>>> select pg_partition_root(c.oid), sum(pg_table_size(c.oid))
>>> from pg_class c
>>> group by 1
On 2018/01/17 22:51, Peter Eisentraut wrote:
> I'm setting this patch to Returned with feedback.
OK. Sorry that I couldn't reply here since the CF started. I have
written some code to implement the pg_partition_root() idea you mentioned
upthread earlier this week, but hasn't been able to share i
I'm setting this patch to Returned with feedback.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut wrote:
> But what are the uses for dealing with partial partition hierarchies?
> How easy do we need to make that?
If you have multilevel partitioning, say partitions per year per site.
What is the volume of 2017 compared to 2016, on each site? I don't
think it needs to be super
On 12/28/17 16:24, David Rowley wrote:
>> select pg_partition_root(c.oid), c.relname, pg_table_size(c.oid)
>> from pg_class c
>> order by 1
>>
>> select pg_partition_root(c.oid), sum(pg_table_size(c.oid))
>> from pg_class c
>> group by 1
>
> That seems much nicer. I assume "root" would mea
On 29 December 2017 at 08:03, Peter Eisentraut
wrote:
> Here is another idea. If we had a function
>
> pg_partition_root(regclass) returns regclass
>
> (returning itself for non-partitioned relations), then users can easily
> construct queries to get the results they want in different shapes, e.g
On 12/18/17 00:17, Amit Langote wrote:
> I agree with the Robert's point which both David and Michael seem to agree
> with that we shouldn't really be changing what pg_relation_size() is doing
> under the covers. And I guess the same for pg_table_size(), too. Both of
> those functions and their s
On Mon, Dec 18, 2017 at 2:17 PM, Amit Langote
wrote:
> Do you (and/or others) think that's something that we can wrap inside a
> built-in function(s), that is, one defined in system_views.sql? Or if we
> decide to have new functions, say, pg_get_partitions() and/or
> pg_get_partition_sizes(), we
Thanks all for your thoughts.
I agree with the Robert's point which both David and Michael seem to agree
with that we shouldn't really be changing what pg_relation_size() is doing
under the covers. And I guess the same for pg_table_size(), too. Both of
those functions and their siblings work wit
On Mon, Dec 18, 2017 at 9:29 AM, Michael Paquier
wrote:
> The barrier here is thin. What's proposed here is already doable with
> a WITH RECURSIVE query. So why not just documenting this query and be
> done with it instead of complicating the code? It seems to me that the
> performance in calling
On Sun, Dec 17, 2017 at 11:54 PM, David Rowley
wrote:
> I'd also vote to leave the relation_size functions alone.
Count me in that bucket as well.
> Perhaps it's worth thinking of changing pg_table_size() instead. We
> have taken measures to try and hide the fact that a table is made up
> of a b
On Sun, Dec 17, 2017 at 9:54 AM, David Rowley
wrote:
> I'd also vote to leave the relation_size functions alone.
>
> Perhaps it's worth thinking of changing pg_table_size() instead. We
> have taken measures to try and hide the fact that a table is made up
> of a bunch of partitions from the user i
On 17 December 2017 at 16:24, Robert Haas wrote:
> On Thu, Dec 14, 2017 at 12:23 AM, Amit Langote
> wrote:
>> You may have guessed from $subject that the two don't work together.
>
> It works exactly as documented:
>
> pg_total_relation_size(regclass) - Total disk space used by the
> specified ta
On Thu, Dec 14, 2017 at 12:23 AM, Amit Langote
wrote:
> You may have guessed from $subject that the two don't work together.
It works exactly as documented:
pg_total_relation_size(regclass) - Total disk space used by the
specified table, including all indexes and TOAST data
It says nothing abou
24 matches
Mail list logo
