Re: WIP patch: reducing overhead for repeat de-TOASTing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP patch: reducing overhead for repeat de-TOASTing
Date: 2008-08-26 00:54:28
Message-ID: 10595.1219712068@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Sun, 2008-06-29 at 16:57 -0400, Tom Lane wrote:
>> After playing with it for a little bit, I'm not convinced that it buys
>> enough performance win to be worth applying --- the restriction of cache
>> lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive.

> Thank you for posting this to the list, this does help us at Truviso
> (sometimes). In some real cases, we're seeing about 15-20x improvement
> of the overall query; going from about 9 seconds to under 500 ms. In
> other cases that could theoretically benefit from TOAST caching, we see
> no improvement at all.

> As you say, the cases where it helps are fairly narrow.

Thanks for giving it a workout. Looks like we do indeed need to work on
the other approach with a more persistent toasted-object cache. But the
numbers you got are good evidence that this will be worth doing if we
can get it right.

I might try to look at this after the September commit fest (but if
anyone else wants to tackle it, feel free!)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-08-26 00:54:52 Re: Implementing cost limit/delays for insert/delete/update/select
Previous Message Tom Lane 2008-08-25 23:02:38 Re: Implementing cost limit/delays for insert/delete/update/select