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

Re: Significantly larger toast tables on 8.4?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, "Alex Hunsaker" <badalex(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Significantly larger toast tables on 8.4?
Date: 2009-01-03 03:30:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 2, 2009 at 8:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Stephen R. van den Berg" <srb(at)cuci(dot)nl> writes:
>>> - I currently have difficulty imagining applications that actually do
>>> lots of substring extractions from large compressible fields.
>> The code that's in there to make this happen was written by people who
>> needed the feature.  They're going to be upset with you if you propose
>> disabling it.

> Why didn't they just turn off compression for the relevant columns?

They did --- with the pre-8.4 code, they had no choice, because the
toast compressor would kick in if it could save even one byte on the
total field size.  That's clearly silly.  We might have gone too far
in the other direction with the current settings, but the point is
that compression isn't always a good thing.

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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Joe ConwayDate: 2009-01-03 03:55:37
Subject: Re: [BUGS] BUG #4599: bugfix for contrib/dblink module
Previous:From: Tom LaneDate: 2009-01-03 03:20:34
Subject: Re: contrib/pg_stat_statements 1226

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