Re: lazy detoasting

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: lazy detoasting
Дата
Msg-id 7b9a0a61-a237-81bf-36a4-46f0baa417d2@anastigmatix.net
обсуждение исходный текст
Ответ на Re: lazy detoasting  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: lazy detoasting  (Chapman Flack <chap@anastigmatix.net>)
Re: lazy detoasting  (Chapman Flack <chap@anastigmatix.net>)
Re: lazy detoasting  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 04/10/2018 04:03 PM, Robert Haas wrote:

> I suspect you want, or maybe need, to use the same snapshot as the
> scan that retrieved the tuple containing the toasted datum.

I'm sure it's worth more than that, but I don't know if it's
implementable.

If I'm a function, and the datum came to me as a parameter, I may
have no way to determine what snapshot the enclosing query used to
obtain the thing passed to me. Or, if I found it myself, say by an
SPI query within the function, usually that's at a level of abstraction
somewhere above what-snapshot-was-used-in-the-scan.

But in both cases, it's expected that I could successfully detoast
either datum if I did so right there on the spot, as that's the usual
convention, right? So at that moment, something in the set of
registered || active snapshots is protecting the tuples I need.

If it's impractical to determine which snapshot is needed (or just
enough work to obviate any benefit of lazy detoasting), I wonder if
there's at least a cheap way to check a particular snapshot
for suitability wrt a given toast pointer. Check a couple usual
suspects, find one most of the time, fall back to eager detoasting
otherwise?

Guess I need to go back for a deeper dive on just what constitutes
a toast pointer. I was skimming last time....

-Chap


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Reopen logfile on SIGHUP
Следующее
От: Martín Marqués
Дата:
Сообщение: vacuum_cost_limit doc description patch