postgres-xc-general Mailing List for Postgres-XC

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

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?

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.

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?


System Configuration:
---------------------
Architecture : x86_64

Operating Systems : CentOS release 6.2 x86_64

Postgres-XC version : Postgres-XC 1.0.0

Compilers used : gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)

----
Tomonari Katsumata