From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | pdarley(at)kinesis-cem(dot)com, darcy(at)wavefire(dot)com, jd(at)www(dot)commandprompt(dot)com, sfrost(at)snowman(dot)net, herve(at)elma(dot)fr, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL clustering VS MySQL clustering |
Date: | 2005-01-22 03:39:28 |
Message-ID: | 20050122.123928.71087515.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Peter, Tatsuo:
>
> would happen with SELECT queries that, through a function or some
> > other mechanism, updates data in the database? Would those need to be
> > passed to pgpool in some special way?
>
> Oh, yes, that reminds me. It would be helpful if pgPool accepted a control
> string ... perhaps one in a SQL comment ... which indicated that the
> statement to follow was, despite appearances, an update. For example:
> --STATEMENT_IS_UPDATE\n
Actually the way judging if it's a "pure" SELECT or not in pgpool is
very simple. pgpool just checkes if the SQL statement exactly begins
with "SELECT" (case insensitive, of course). So, for example, you
could insert an SQL comment something like "/*this SELECT has side
effect*/ at the beginning of line to indicate that pgpool should not
send this query to the slave.
> The alternative is, of course, that pgPool direct all explicit transactions to
> the master ... which is a good idea anyway. So you could do:
>
> BEGIN;
> SELECT some_update_function();
> COMMIT;
Yes. pgpool has already done this in load balancing. Expanding this
for Slony-I is pretty easy.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-01-22 04:22:13 | Re: inheritance performance |
Previous Message | Tatsuo Ishii | 2005-01-22 03:13:00 | Re: PostgreSQL clustering VS MySQL clustering |