From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Dynamic Partitioning using Segment Visibility Maps |
Date: | 2008-01-07 12:59:01 |
Message-ID: | 47822215.9080200@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Csaba,
Csaba Nagy wrote:
> One additional thought: what about a kind of "segment fill factor" ?
> Meaning: each segment has some free space reserved for future
> updates/inserts of records in the same range of it's partitioning
> constraint. And when inserting/updating you put the new record into the
> corresponding segment... just like a very coarse clustering.
Hm.. yeah. That way, a few writes to a "read optimized" segment could be
accepted, without having to drop the optimization immediately. And the
other way around: generally prevent having to drop the optimization by
forcing tuples to be written to a segment with matching min/max tuples.
Although, that's not exactly trivial, I think.
However, for tables which don't fit the use case of SE, people certainly
don't want such a fill factor to bloat their tables.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Doug Knight | 2008-01-07 13:07:32 | Re: Tuning Postgresql on Windows XP Pro 32 bit |
Previous Message | Alvaro Herrera | 2008-01-07 12:18:24 | Re: Bug: Unreferenced temp tables disables vacuum to update xid |