Re: Significantly larger toast tables on 8.4?

From: "Alex Hunsaker" <badalex(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Significantly larger toast tables on 8.4?
Date: 2009-01-03 06:16:58
Message-ID: 34d269d40901022216t67941d4x6245033fc5601340@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 2, 2009 at 20:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> One point that nobody seems to have focused on is whether Alex's
> less-compressed table is faster or slower to access than the original.
> I dunno if he has any easy way of investigating that for his typical
> query mix, but it's certainly a fair question to ask.

Other than the quick pgbench numbers I posted upthread where 8.4 blew
8.3 out of the water with a substring. Not really, this table is
mainly insert. A few times a day everything inserted that day gets
selected. So while I'm almost positive 8.4 is faster, its probably
not really noticeable in my workload. That being said here are some
quick numbers:

(see attached q.sql for how uninteresting the query is, also this is
so slow mainly due to the lack of it using an index, it seq-scans the
entire table :()
./pgbench -T600 -n -f q.sql
8.4 with 8.3 TOAST: 6.250298
8.4: 6.460312

(note I dont actually use substring on this table...)
./pgbench -T60 -n -f substring.sql
8.4 w 8.3 TOAST: 12.613394
8.4: 6347.456596

Attachment Content-Type Size
substring.sql application/octet-stream 100 bytes
q.sql application/octet-stream 365 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2009-01-03 06:32:00 Re: Significantly larger toast tables on 8.4?
Previous Message Andrew Chernow 2009-01-03 05:17:16 Re: Significantly larger toast tables on 8.4?