Re: Dead code in toast_fetch_datum_slice?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Dead code in toast_fetch_datum_slice?
Date: 2018-12-10 18:23:19
Message-ID: 20181210182319.xoyi2w7ftpk35qkm@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-Dec-10, Paul Ramsey wrote:

> Your analysis looks correct to me, I'm pretty sure I had the same reaction,
> first time I read through. It would be nice to handle partial decompression
> all the way down at this level, but unfortunately the comment at the
> Assert() is right: there's no way to know how many of the toasted pieces
> need to be read in order to have enough compressed input to create the
> desired amount of decompressed output, so there's no choice except to read
> the whole compressed thing, even in a slicing context.

It'd be useful to have some sort of iterator-style API for detoasting.
If you need more data, just call it again. It's more wasteful if you
end up retrieving all of the toasted data, but if you just need a
fraction it's obviously a win.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-12-10 18:30:11 Re: Dead code in toast_fetch_datum_slice?
Previous Message Stephen Frost 2018-12-10 18:20:18 Re: [HACKERS] Bug when dumping "empty" operator classes