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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WIP patch: reducing overhead for repeat de-TOASTing
Date: 2008-08-25 17:42:30
Message-ID: 1219686150.6213.195.camel@dell.linuxdev.us.dell.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
> (For example, sorts that involve toasted sort keys continue to suck,
> because the tuples being sorted aren't in Slots.) It would probably
> fix the specific case that the PostGIS hackers were complaining of,
> but I think we need something more.
>
> Still, I wanted to get it into the archives because the idea of indirect
> toast pointers might be useful for something else.
>

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. It's
also very susceptible to changes in the plan. For instance, if the
toasted value is on one side of a nested loop, the patch helps a
lot; but it goes back to the performance of unpatched PostgreSQL for the
same plan if the nested loop is inverted, as shown below.

Regards,
Jeff Davis

[ plan estimates are omitted for readability ]

----------- UNPATCHED -----------

Nested Loop (actual time=3.021..1020.923 rows=1000 loops=1)
-> Seq Scan on toasted (actual time=0.016..0.017 rows=1 loops=1)
-> Seq Scan on a (actual time=0.016..0.735 rows=1000 loops=1)
Total runtime: 1021.397 ms

Nested Loop (actual time=1.352..1037.207 rows=1000 loops=1)
-> Seq Scan on a (actual time=0.007..0.364 rows=1000 loops=1)
-> Seq Scan on toasted (actual time=0.001..0.002 rows=1 loops=1000)
Total runtime: 1037.653 ms

------------ PATCHED ------------
-- patch helps
Nested Loop (actual time=1.266..2.247 rows=1000 loops=1)
-> Seq Scan on toasted (actual time=0.003..0.072 rows=1 loops=1)
-> Seq Scan on a (actual time=0.006..0.328 rows=1000 loops=1)
Total runtime: 2.519 ms

-- patch has no effect
Nested Loop (actual time=1.283..1012.371 rows=1000 loops=1)
-> Seq Scan on a (actual time=0.010..0.719 rows=1000 loops=1)
-> Seq Scan on toasted (actual time=0.001..0.059 rows=1 loops=1000)
Total runtime: 1012.973 ms

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-08-25 17:56:16 Re: initdb change
Previous Message Joshua Drake 2008-08-25 17:26:15 Re: initdb change