From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Dave Page <dpage(at)pgadmin(dot)org>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> |
Subject: | Re: FSM rewrite committed, loose ends |
Date: | 2008-10-02 12:37:59 |
Message-ID: | 23820.1222951079@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Following that philosophy, I think the idea of adding a new optional
> "fork name" argument to pg_relation_size() is the right thing to do:
> pg_relation_size('footable') for size of the main data fork
> pg_relation_size('footable', 'fsm') for FSM size
+1. Note that the second form should also accept 'main' or some such
for orthogonality.
> There's currently two variants of both pg_relation_size and
> pg_total_relation_size, one takes an OID and one takes a relation name
> as argument. Any objections to having just one of each function, taking
> a 'regclass'? The user-visible behavior wouldn't change, but I thought
> I'd ask first in case I'm missing something.
Um, it would only not change for someone typing
pg_relation_size('literal'). Something like this:
select sum(pg_relation_size(relname)) from pg_class
would fail for lack of an implicit cast from name to regclass.
Now the above is pretty stupid --- it would be faster and more
schema-safe to be passing pg_class.oid --- so maybe we don't care
about breaking it.
On the whole I think it's probably a good change despite possible
incompatibility.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Brian Hurt | 2008-10-02 13:07:40 | Re: Block-level CRC checks |
Previous Message | Tom Lane | 2008-10-02 12:27:47 | Re: Re: [COMMITTERS] pgsql: Allow pg_regress to be run outside the build tree. |