Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Parallel Seq Scan
Date
Msg-id 20151011235618.GA125073@tornado.leadboat.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel Seq Scan
List pgsql-hackers
On Sat, Sep 26, 2015 at 04:09:12PM -0400, Robert Haas wrote:
> +/*-------------------------------------------------------------------------
> + * datumSerialize
> + *
> + * Serialize a possibly-NULL datum into caller-provided storage.

> +void
> +datumSerialize(Datum value, bool isnull, bool typByVal, int typLen,
> +               char **start_address)
> +{
> +    int        header;
> +
> +    /* Write header word. */
> +    if (isnull)
> +        header = -2;
> +    else if (typByVal)
> +        header = -1;
> +    else
> +        header = datumGetSize(value, typByVal, typLen);
> +    memcpy(*start_address, &header, sizeof(int));
> +    *start_address += sizeof(int);
> +
> +    /* If not null, write payload bytes. */
> +    if (!isnull)
> +    {
> +        if (typByVal)
> +        {
> +            memcpy(*start_address, &value, sizeof(Datum));
> +            *start_address += sizeof(Datum);
> +        }
> +        else
> +        {
> +            memcpy(*start_address, DatumGetPointer(value), header);
> +            *start_address += header;
> +        }
> +    }
> +}

I see no mention in this thread of varatt_indirect, but I anticipated
datumSerialize() reacting to it the same way datumCopy() reacts.  If
datumSerialize() can get away without doing so, why is that?



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Postgres service stops when I kill client backend on Windows
Next
From: Peter Geoghegan
Date:
Subject: INSERT ... ON CONFLICT documentation clean-up patch