On Thu, Aug 30, 2012 at 6:59 PM, Tomonari Katsumata <
kat...@po...> wrote:
> Hi, I'm checking behavior of Postgres-XC 1.0.0.
>
> and I have two questions.
>
> 1) pg_stat_statements
> when I run INSERT statement to a table with generate_series function,
> I can't catch the process from pg_stat_statements on Datanode.
> but I can catch it from pg_stat_statements on Coordinator.
>
> so I think generate_series is parsed and divided on Coordinator, and then
> each INSERT statement is delivered to each Datanode(this is very short
> time).
> is this right?
>
Yes this is right for a hash, modulo or round robin table. You need to
distribute the data to remote nodes.
If you do it for a replicated table, you can push down generate_series
safely so you will be able to see it on Datanodes.
> 2) pg_locks
> when I run SELECT statement to a table on the first of the trunsaction,
> I can't catch the lock information(AccessShareLock) from pg_locks on
> Datanode.
> but I can catch it from pg_locks on Coordinator.
>
The query is run on the remote nodes, so you will get it there. Coordinator
has no data.
>
> if I run modify statement(INSERT/UPDATE/DELETE) before SELECT statement,
> the lock information(AccessShareLock) is appered with the SELECT statement.
>
> I think this behavior is related with virtual-transaction.
> and I think AccessShareLock never blocking any other queries,
> so this does not become any problems.
> is this right?
>
Yes. The lock info is maintained on remote nodes where the transaction has
run.
--
Michael Paquier
http://michael.otacoo.com
|
