From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: TOAST usage setting |
Date: | 2007-05-30 17:41:05 |
Message-ID: | 465DB731.9020106@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> What you will see is that pushing TEXT to a TOAST column allows quick
> access to non-TOAST values and single-row TOAST values, but accessing
> all TOAST columns is slower than accessing them in the heap, by a factor
> of 3-18x.
>
> Looking at the chart, it seems 512 is the proper breakpoint for TOAST
> because 512 gives us a 2x change in accessing non-TOAST values and
> single-row TOAST values, and it is only 2x slower to access all TOAST
> values than we have now.
I don't understand why that point is any better than any other point.
> Of course, this has all the data in the cache, but if the cache is
> limited, pushing more to TOAST is going to be a bigger win.
... assuming that you don't access the TOASTed data.
> In general,
> I would guess that the number of times all >512 byte rows are accessed
> is much less than the number of times that pushing those >512 byte
> values to TOAST will give a speedup.
Maybe. Maybe not. I wonder how the access times for a single row change
when you have a table that doesn't fit in cache. Especially after some
random updates, so that the toast is not clustered in the same order as
the heap.
The bottom line is that the optimal threshold depends on your application.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-30 18:01:44 | Re: Ye olde drop-the-database-you-just-left problem |
Previous Message | Brian Hurt | 2007-05-30 17:36:14 | Re: Ye olde drop-the-database-you-just-left problem |