From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Subject: Re: [HACKERS] Maintaining cluster order on insert
Date: Fri, 11 Aug 2006 13:36:42 -0700
Organization: Hub.Org Networking Services
Lines: 27
Message-ID: <ebipoh$1538$1@news.hub.org>
References: <44DA31B1.3090700@enterprisedb.com>
	<28914.1155154622@sss.pgh.pa.us>
	<36e682920608091347m4e075a8cv6a04e3c4d97ed6f4@mail.gmail.com>
	<430d92a20608091831w6e59da84k48a58110cb98e8d6@mail.gmail.com>
	<9461.1155178183@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.4 (X11/20060713)
In-Reply-To: <9461.1155178183@sss.pgh.pa.us>
To: pgsql-patches@postgresql.org

Tom Lane wrote:
> Gene <genekhart@gmail.com> writes:
>> I have a table that inserts lots of rows (million+ per day) int8 as primary
>> key, and I cluster by a timestamp which is approximately the timestamp of
>> the insert...
> 
> ISTM you should hardly need to worry about clustering that --- the data
> will be in timestamp order pretty naturally.

In my case my biggest/slowest tables are clustered by zip-code (which
does a reasonable job at keeping counties/cities/etc on the
same pages too).  Data comes in constantly (many records per minute, as
we ramp up), pretty uniformly across the country; but most queries
are geographically bounded.  The data's pretty much insert-only.

If I understand Heikki's patch, it would help for this use case.


> Your best bet might be to partition the table into two subtables, one
> with "stable" data and one with the fresh data, and transfer rows from
> one to the other once they get stable.  Storage density in the "fresh"
> part would be poor, but it should be small enough you don't care.

Hmm... that should work well for me too.  Not sure if the use-case
I mentioned above is still compelling anymore; since this seems like
it'd give me much of the benefit; and I don't need an excessive
fillfactor on the stable part of the table.