Skip site navigation (1) Skip section navigation (2)

Re: stack usage in toast_insert_or_update()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: stack usage in toast_insert_or_update()
Date: 2007-01-31 17:41:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On 1/31/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The toast code takes pains to ensure that the tuples it creates won't be
>> subject to re-toasting.  Else it'd be an infinite recursion.

> I think I found it. The toast_insert_or_update() function gets into an
> unnecessary recursion because of alignment issues. It thus toasts
> already toasted data.  This IMHO might be causing unnecessary
> overheads for each toast operation.

Interesting --- I'd never seen this because both of my usual development
machines have MAXALIGN 8, and it works out that that makes
TOAST_MAX_CHUNK_SIZE 1986, which makes the actual toasted tuple size
2030, which maxaligns to 2032, which is still less than
TOAST_TUPLE_THRESHOLD.  I think the coding was implicitly assuming that
TOAST_TUPLE_THRESHOLD would itself be a maxalign'd value, but it's not
necessarily (and in fact not, with the current page header size ---
I wonder whether the bug was originally masked because the page header
size was different??)

We can't change TOAST_MAX_CHUNK_SIZE without forcing an initdb, but I
think that it would be safe to remove the MAXALIGN'ing of the tuple
size in the tests in heapam.c, that is

    if (HeapTupleHasExternal(tup) ||
        (MAXALIGN(tup->t_len) > TOAST_TUPLE_THRESHOLD))
        heaptup = toast_insert_or_update(relation, tup, NULL);
        heaptup = tup;


    if (HeapTupleHasExternal(tup) ||
        (tup->t_len > TOAST_TUPLE_THRESHOLD))
        heaptup = toast_insert_or_update(relation, tup, NULL);
        heaptup = tup;

which'll save a cycle or two as well as avoid this corner case.
It seems like a number of the uses of MAXALIGN in tuptoaster.c
are useless/bogus as well.  Comments?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2007-01-31 18:16:26
Subject: Re: Talks for OSCON? Only 5 days left!
Previous:From: David FetterDate: 2007-01-31 17:35:38
Subject: Re: Modifying and solidifying contrib

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group