Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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: substring.sql
Description: application/octet-stream (99 bytes)
Attachment: q.sql
Description: application/octet-stream (364 bytes)

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group