Re: PostgreSQL clustering VS MySQL clustering
От | Tatsuo Ishii |
---|---|
Тема | Re: PostgreSQL clustering VS MySQL clustering |
Дата | |
Msg-id | 20050122.123928.71087515.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: PostgreSQL clustering VS MySQL clustering (Josh Berkus <josh@agliodbs.com>) |
Список | 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
В списке pgsql-performance по дате отправления: