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

Re: Bug with plpgsql, temp tables and TOAST?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Matthijs Bomhoff <matthijs(at)quarantainenet(dot)nl>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bug with plpgsql, temp tables and TOAST?
Date: 2011-07-01 21:59:37
Message-ID: 6038.1309557577@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Hmm, so what's happening here, I think, is that the value is getting
> assigned to the record variable without detoasting.  I guess we should
> detoast the value prior to assigning it, but it seems to me that that
> would have a large performance penalty for other cases in which the
> toast table is not dropped; in fact, you can even imagine some cases in
> which the toasted value is not even accessed, so getting to the point of
> detoasting it would be a severe penalization.

Yeah, we have seen similar reports before, and concluded that forcibly
detoasting on the remote chance that the toast table wouldn't stick
around was just untenable from a performance standpoint.  It's annoying
but I don't see a good compromise solution ATM.

Pavel was working recently on a hack to prevent repeated detoastings,
which is at least somewhat related to this issue.  I don't recall that
anyone liked his hack though ...

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2011-07-02 03:35:21
Subject: Re: BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Previous:From: Tom LaneDate: 2011-07-01 20:27:36
Subject: Re: view + explain + index scan -> bogus varno: 65001 (with some variations)

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