Re: PostgreSQL clustering VS MySQL clustering

From: Matt Clark <matt(at)ymogen(dot)net>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL clustering VS MySQL clustering
Date: 2005-01-21 17:35:13
Message-ID: 41F13D51.9070608@ymogen.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Yes, I wasn't really choosing my examples particularly carefully, but I
think the conclusion stands: pgpool (or anyone/thing except for the
server) cannot in general tell from the SQL it is handed by the client
whether an update will occur, nor which tables might be affected.

That's not to say that pgpool couldn't make a good guess in the majority
of cases!

M

Joshua D. Drake wrote:

> Matt Clark wrote:
>
>> Presumably it can't _ever_ know without being explicitly told,
>> because even for a plain SELECT there might be triggers involved that
>> update tables, or it might be a select of a stored proc, etc. So in
>> the general case, you can't assume that a select doesn't cause an
>> update, and you can't be sure that the table list in an update is a
>> complete list of the tables that might be updated.
>
>
> Uhmmm no :) There is no such thing as a select trigger. The closest
> you would get
> is a function that is called via select which could be detected by
> making sure
> you are prepending with a BEGIN or START Transaction. Thus yes pgPool
> can be made
> to do this.
>
> Sincerely,
>
> Joshua D. Drake
>
>
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2005-01-21 17:47:53 Re: PostgreSQL clustering VS MySQL clustering
Previous Message Richard Huxton 2005-01-21 17:20:55 Re: Profiling a function...