Re: PostgreSQL clustering VS MySQL clustering - Mailing list pgsql-performance

From Matt Clark
Subject Re: PostgreSQL clustering VS MySQL clustering
Date
Msg-id 41F13D51.9070608@ymogen.net
Whole thread Raw
In response to Re: PostgreSQL clustering VS MySQL clustering  ("Joshua D. Drake" <jd@commandprompt.com>)
List 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
>
>
>

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Profiling a function...
Next
From: Josh Berkus
Date:
Subject: Re: PostgreSQL clustering VS MySQL clustering