Re: invalidating cached plans

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: invalidating cached plans
Дата
Msg-id 87k6oat9fa.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: invalidating cached plans  (Michael Adler <adler@pobox.com>)
Список pgsql-hackers
Michael Adler <adler@pobox.com> writes:

> Our current load distributors, like pgpool, have no way of knowing the
> side effects of backend functions. It would be interesting if the
> client could send each potential query to the master saying, "execute
> this query if there are side effects, otherwise do no operation and
> and let me execute this read-only query on a replicated copy."

Wouldn't you want to handle that the other way around? I mean there's not much
point in distributing the load if it still requires passing everything through
a single point of contention anyways.

So I think the feature you really want is a kind of read-only mode. "execute
this but if it tries to have any side effects abort and give me an error"

That seems like a reasonably useful thing for other circumstances as well.
DBAs sanity checking a database that don't want to make any modifications, low
privilege users like cron jobs that aren't supposed to be making
modifications, etc.

In an ideal world it would combine well with having tablespaces be on
read-only media.

I had the impression Postgres wants to make modifications to data for purely
read-only operations though. It might be hard to detect "side effects" that
the user would care about distinct from invisible internal operations.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Avoiding tuple construction/deconstruction during joining
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [pgsql-hackers-win32] snprintf causes regression tests