From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Modifying TOAST thresholds |
Date: | 2007-04-27 18:55:41 |
Message-ID: | 601wi5sl3m.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> Chris Browne <cbbrowne(at)acm(dot)org> writes:
>> bruce(at)momjian(dot)us (Bruce Momjian) writes:
>>> I have seen no one do peroformance testing of this, so it seems it
>>> will have to wait for 8.4.
>
>> I didn't have time...
>
>> (e.g. - we've got a case where dropping the threshold to ~900 bytes
>> would give us a big win for certain databases and tables.)
>
> How do you know? Seems like you've got a readymade test case there.
I did some testing with Known Scenario, and found, indeed, that there
was a significant gain to be had. I documented it at least partially
on March 21...
<http://www.nabble.com/Re%3A-TOASTing-smaller-things-p9602766.html>
Unfortunately, the sample query that I used to validate usefulness
isn't one I can share :-(.
More importantly, it's only one test case, and is strongly influenced
by some *very* strong regularity to the patterns of updates that take
place to the table that I looked at. It's not nearly good enough to
treat as a generalizable case.
--
output = ("cbbrowne" "@" "linuxfinances.info")
http://linuxdatabases.info/info/spiritual.html
MICROS~1 is to quality software what MacDonalds is to gourmet cooking
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-27 22:06:35 | Re: BUG #3244: problem with PREPARE |
Previous Message | Jim Nasby | 2007-04-27 17:59:24 | Re: Avoiding unnecessary reads in recovery |