Re: Vertical Partitioning with TOAST - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Vertical Partitioning with TOAST
Date
Msg-id 1141497650.3772.12.camel@localhost.localdomain
Whole thread Raw
In response to Re: Vertical Partitioning with TOAST  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Ühel kenal päeval, L, 2006-03-04 kell 10:31, kirjutas Tom Lane:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
> >> Also getting rid of toast index and start using ctids directly would be
> >> a big bonus.
> >> When using direct ctids we could use either ctid chains or some sort of
> >> skiplist for access to N-th TOAST chunk.
> 
> > I suppose this would mean that you couldn't use vacuum on the toast
> > table anymore.
> 
> Another problem with it is that it'd destroy the current optimizations
> that allow partial fetches of uncompressed TOASTed fields to be fast.
> You couldn't fetch page N of a TOAST datum without reading all the pages
> before it.
> 
> I suppose the objection that toast tables wouldn't be regular tables
> anymore might not be fatal, but you'll certainly get some pushback if
> you try to take away the direct-access optimizations.

That's why I was suggesting skiplist instead on simple linked lists.

Another way would be to put a list of all toast ctids for your whole
toasted field in the first page(s) of the toast.

That way you will still have option of fast access to any partial of the
field, most likely even faster than with current implementation, as you
have to touch less pages. And you can have it also for compressed fields
if you store uncompressed offsets.

-----------------
Hannu






pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Constraint Exclusion and Partition Locking
Next
From: "Michael Paesold"
Date:
Subject: Re: Not so happy with psql's new multiline behavior