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

Re: stack usage in toast_insert_or_update()

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: stack usage in toast_insert_or_update()
Date: 2007-02-01 16:51:46
Message-ID: 45C21AA2.1060309@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 1/31/2007 12:41 PM, Tom Lane wrote:
> "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);
>     else
>         heaptup = tup;
> 
> becomes
> 
>     if (HeapTupleHasExternal(tup) ||
>         (tup->t_len > TOAST_TUPLE_THRESHOLD))
>         heaptup = toast_insert_or_update(relation, tup, NULL);
>     else
>         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?

Can't we maxalign the page header in the calculations?


Jan

> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-02-01 16:57:31
Subject: Re: Estimation error in n_dead_tuples
Previous:From: Hans-Juergen SchoenigDate: 2007-02-01 16:37:24
Subject: Re: max_locks_per_transactions ...

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