|From:||Chapman Flack <chap(at)anastigmatix(dot)net>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: lazy detoasting|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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
Guess I need to go back for a deeper dive on just what constitutes
a toast pointer. I was skimming last time....
|Next Message||Martín Marqués||2018-04-10 21:13:48||vacuum_cost_limit doc description patch|
|Previous Message||Tom Lane||2018-04-10 21:00:33||Re: Reopen logfile on SIGHUP|