Re: pg_relation_size performance issue

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_relation_size performance issue
Дата
Msg-id 30361.1433425855@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_relation_size performance issue  (Hans Guijt <hg@terma.com>)
Ответы Re: pg_relation_size performance issue  (Melvin Davidson <melvin6925@gmail.com>)
Список pgsql-general
Hans Guijt <hg@terma.com> writes:
> I have a Postgres 9.3.7 database, freshly created on Ubuntu 14 LTS 64 bit, and at this time almost completely empty.
I'mattempting to find the size of a table, using the following code: 
> SELECT
>   pg_relation_size (stat.relid),
>   CASE WHEN cl.reltoastrelid = 0 THEN
>   0
>   ELSE
>   pg_relation_size (cl.reltoastrelid) + COALESCE ((
>   SELECT SUM (pg_relation_size (indexrelid)) FROM pg_index WHERE indrelid=cl.reltoastrelid
>   ), 0)::int8
> END,
> COALESCE ((SELECT SUM (pg_relation_size (indexrelid)) FROM pg_index WHERE indrelid=stat.relid), 0)::int8
> FROM pg_stat_all_tables stat
> JOIN pg_class cl ON cl.oid=stat.relid
> JOIN pg_namespace ns ON cl.relnamespace=ns.oid
> WHERE UPPER (cl.relname) = UPPER ('sensor')
>    AND UPPER (ns.nspname) = UPPER ('devtest')

Getting rid of the useless join to pg_stat_all_tables would probably help;
there's a lot of computation in that view.

            regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Row visibility issue with consecutive triggers, one being DEFERRED