Re: Idea about estimating selectivity for single-column expressions

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Idea about estimating selectivity for single-column expressions
Дата
Msg-id
26388.1250706159@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Idea about estimating selectivity for single-column expressions Tom Lane <tgl@sss.pgh.pa.us>
Re: Idea about estimating selectivity for single-column expressions Greg Stark <gsstark@mit.edu>
Re: Idea about estimating selectivity for single-column expressions Tom Lane <tgl@sss.pgh.pa.us>
Re: Idea about estimating selectivity for single-column expressions Greg Stark <gsstark@mit.edu>
Re: Idea about estimating selectivity for single-column expressions Tom Lane <tgl@sss.pgh.pa.us>
Re: Idea about estimating selectivity for single-column expressions Greg Stark <gsstark@mit.edu>
Re: Idea about estimating selectivity for single-column expressions Tom Lane <tgl@sss.pgh.pa.us>
Re: Idea about estimating selectivity for single-column expressions Josh Berkus <josh@agliodbs.com>
Re: Idea about estimating selectivity for single-column expressions Robert Haas <robertmhaas@gmail.com>
Re: Idea about estimating selectivity for single-column expressions Robert Haas <robertmhaas@gmail.com>
Greg Stark  writes:
> Another thought. In the above case it would actually be fine to catch
> the error with PG_TRY() without a subtransaction. As long as no shared
> database state has been modified when the error is thrown then the
> subtransaction isn't needed to roll them back.

I think catching general errors coming out of possibly user-defined code
without using a subtransaction is just too scary to contemplate.
There's too much stuff that could need to be cleaned up and would not
have been.

It may be that a subtransaction will actually be acceptable overhead,
as long as we don't go overboard and invoke this mechanism for "simple"
WHERE clauses.  Hard to tell without coding it up and testing it though.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Josh Berkus
Дата:
От: Tom Lane
Дата:
FAQ