Re: FSM rewrite committed, loose ends

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: FSM rewrite committed, loose ends
Дата
Msg-id 23820.1222951079@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: FSM rewrite committed, loose ends  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: FSM rewrite committed, loose ends  (Robert Treat <xzilla@users.sourceforge.net>)
Список pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Allow pg_regress to be run outside the build tree.
Следующее
От: Brian Hurt
Дата:
Сообщение: Re: Block-level CRC checks