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
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 |