Re: PostgreSQL clustering VS MySQL clustering

Поиск
Список
Период
Сортировка
От Matt Clark
Тема Re: PostgreSQL clustering VS MySQL clustering
Дата
Msg-id 41F13D51.9070608@ymogen.net
обсуждение исходный текст
Ответ на Re: PostgreSQL clustering VS MySQL clustering  ("Joshua D. Drake" <jd@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: Profiling a function...
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: PostgreSQL clustering VS MySQL clustering