Re: Manipulating complex types as non-contiguous structures in-memory

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Manipulating complex types as non-contiguous structures in-memory
Date: 2015-02-12 13:52:56
Message-ID: CA+TgmoZeHXeJxYV2YzG5c0MLX-OuUNENDRZDy=TJr-RdARH=XQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 10, 2015 at 3:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've now taken this idea as far as building the required infrastructure
> and revamping a couple of array operators to use it. There's a lot yet
> to do, but I've done enough to get some preliminary ideas about
> performance (see below).

Very impressive. This is something that's been mentioned before and
which I always thought would be great to have, but I didn't expect it
would be this easy to cobble together a working implementation. Or
maybe "easy" isn't the right term, but this isn't a very big patch.

> BTW, I'm not all that thrilled with the "deserialized object" terminology.
> I found myself repeatedly tripping up on which form was serialized and
> which de-. If anyone's got a better naming idea I'm willing to adopt it.

My first thought is that we should form some kind of TOAST-like
backronym, like Serialization Avoidance Loading and Access Device
(SALAD) or Break-up, Read, Edit, Assemble, and Deposit (BREAD). I
don't think there is anything per se wrong with the terms
serialization and deserialization; indeed, I used the same ones in the
parallel-mode stuff. But they are fairly general terms, so it might
be nice to have something more specific that applies just to this
particular usage.

I found the notion of "primary" and "secondary" TOAST pointers to be
quite confusing. I *think* what you are doing is storing two pointers
to the object in the object, and a pointer to the object is really a
pointer to one of those two pointers to the object. Depending on
which one it is, you can write the object, or not. This is a clever
representation, but it's hard to wrap your head around, and I'm not
sure "primary" and "secondary" are the best names, although I don't
have an idea as to what would be better. I'm a bit confused, though:
once you give out a secondary pointer, how is it safe to write the
object through the primary pointer?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2015-02-12 13:55:33 Logical decoding document
Previous Message Marco Nenciarini 2015-02-12 13:50:21 Re: File based Incremental backup v8