Adding "quota user limit" using triggers

Поиск
Список
Период
Сортировка
От Andrea Peri
Тема Adding "quota user limit" using triggers
Дата
Msg-id BANLkTi=kryLhVhwjVEor4DeZy=QP3LMiBA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Adding "quota user limit" using triggers  ("David Johnston" <polobo@yahoo.com>)
Список pgsql-general
>on 06/08/11 11:14 PM, Andrea Peri wrote:
>Hi,
>
>
>Is possible the limit the size of an user (quota user) as space allocated in a tablespace ?
>I don't find this option in the 9.0 version of PG,
>so I think it is not available.
>
>Perhaps it should be possible to simulate it using triggers.
>
>
>However before start to work on it , I like to have a confirm and if there is some documentation or information on this
>problem available.

>what exactly would this limit?
>
>
>The total size of tables created by that user regardless of what role inserted data into said tables? There's really no way to >track the data written by a user into tables that multiple users have insert/update privs to. and does it include older tuple >versions that aren't yet vacuumed? calculating pg_total_relation_size is fairly expensive, too, it requires scanning the table >and ancilliary items (indexes, toast storage) to sum up the number of blocks allocated.
>

I guess the quota limit should be applied to the owner of the table is also the owner of the indexes, sequences, and so on..
regardless of which has inserted on it.
And also regardless of vacuumed space.

>calculating pg_total_relation_size is fairly expensive, too, it requires scanning the table >and ancilliary items (indexes, toast
>storage) to sum
up the number of blocks allocated.

yes I think this is a fairly expensive task,

But is for me necessary.


--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

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

Предыдущее
От: Clemens Schwaighofer
Дата:
Сообщение: Re: plpgsql function with update and seeing changed data from outside during run
Следующее
От: Willy-Bas Loos
Дата:
Сообщение: Re: [PERFORM] [PERFORMANCE] expanding to SAN: which portion best to move