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 по дате отправления: