Re: PostgreSQL clustering VS MySQL clustering

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

In response to

Browse pgsql-performance by date

  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