To: Robert Haas <robertmhaas@gmail.com>
cc: Kenneth Marshall <ktm@rice.edu>,
 Mladen Gogala <mladen.gogala@vmsinfo.com>,
	pgsql-performance@postgresql.org
Subject: Re: Select count(*), the sequel 
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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 26 Oct 2010 18:45:30 -0400"
Date: Tue, 26 Oct 2010 18:51:31 -0400
Message-ID: <2091.1288133491@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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