From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kenneth Marshall <ktm@rice.edu>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Select count(*), the sequel
Date: Tue, 26 Oct 2010 18:51:31 -0400
Message-ID: <2091.1288133491@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTik6ifMywZq7C1_MiHLafOQ53_OXreHYQdps3GqP@mail.gmail.com>
References: <4CB9D89E.7050701@vmsinfo.com>
<20101016184443.GA4993@aart.is.rice.edu>
<AANLkTik6ifMywZq7C1_MiHLafOQ53_OXreHYQdps3GqP@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> I don't think this is due to fillfactor - the default fillfactor is
> 100, and anyway we ARE larger on disk than Oracle. We really need to
> do something about that, in the changes to NUMERIC in 9.1 are a step
> in that direction, but I think a lot more work is needed.
Of course, the chances of doing anything more than extremely-marginal
kluges without breaking on-disk compatibility are pretty tiny. Given
where we are at the moment, I see no appetite for forced dump-and-reloads
for several years to come. So I don't foresee that anything is likely
to come of such efforts in the near future. Even if somebody had a
great idea that would make things smaller without any other penalty,
which I'm not sure I believe either.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, ktm@rice.edu, mladen.gogala@vmsinfo.com
Subject: Re: Select count(*), the sequel
In-Reply-To: <2091.1288133491@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox