Re: procpid?
От | Gurjeet Singh |
---|---|
Тема | Re: procpid? |
Дата | |
Msg-id | BANLkTi=62WZjmU0kGxT8cvC-tMUX2OHZ4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: procpid? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: procpid?
|
Список | pgsql-hackers |
On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas <robertmhaas@gmail.com> wrote:
I wanted to address consistency issue in the previous mail, but then wanted that to be left for later.
We can provide consistency the same way pg_locks provides; take a snapshot on first request within a transaction, and reuse that snapshot for subsequent calls. In this case we might want to go a bit finer grained by providing a snapshot for every query.
On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:Well, that would probably be a lot slower, and wouldn't necessarily
> Why not expose this new information as functions instead of a new view, like
> we do for pg_is_in_replication(). People can use whatever alias they want in
> the queries they write.
>
> SELECT get_current_query(pid), is_idle(pid), is_idle_in_transaction(pid),
> transaction_start_time(pid), .... FROM (select procpid as pid FROM
> pg_stat_activity);
>
> Then pg_activity (or whatever we name it later) would also be a view on top
> of these functions.
deliver as consistent a snapshot of system activity. It's better to
have one set-returning function that dumps out all the data in a
single pass.
I wanted to address consistency issue in the previous mail, but then wanted that to be left for later.
We can provide consistency the same way pg_locks provides; take a snapshot on first request within a transaction, and reuse that snapshot for subsequent calls. In this case we might want to go a bit finer grained by providing a snapshot for every query.
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: