Gene <[EMAIL PROTECTED]> writes:
> "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
Gene wrote:
You are correct the main part I'm worried about is the updates, being
so far from the originals.
Yeah, you won't benefit from the patch at all.
The reason I'm doing the clustering is I was hoping that with the
"stable" non-updating partitions I could execute a CLUSTER at night
(sl
Jonah H. Harris wrote:
On 8/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
UPDATE tries to place the new tuple on the same page it's already
on.
I think he meant for INSERT.
Right. Update is indeed taken care of already.
One example where this would help would be a customer_history table that
You are correct the main part I'm worried about is the updates, being so far from the originals. fyi I
am partitioning the tables by the timestamp column,vacuum analyzing once per hour, creating one child
partition per day in a cron job. Because I'm using hibernate for database abstraction (statele
Gene <[EMAIL PROTECTED]> 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 beforehand and is therefore in increasing order and doesn't
> change. Most of the rows are updated
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 beforehand and is therefore in increasing order and doesn't change. Most of the rows are updated about 3 times over time roughly within th
On 8/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
UPDATE tries to place the new tuple on the same page it's already
on.
I think he meant for INSERT.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 2nd Floor
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> While thinking about index-organized-tables and similar ideas, it
> occurred to me that there's some low-hanging-fruit: maintaining cluster
> order on inserts by trying to place new heap tuples close to other
> similar tuples.
Doesn't this happen
