Andreas,
On 3/7/07 11:45 AM, "Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]>
wrote:
> Whoa, do you have anything to back that up ?
Sure - when we start to consider designs that implement advanced data
management features, we run into problems with the architecture of
"tables->tables->tables...". Here are some examples:
1 - people think of partitions as a logical building block for tables, they
would like to move partitions around underneath a table without the table
definition being involved. In the current implementation, there are
explicit linkages between the table definition and the child tables -
imagine an "ALTER TABLE foo_parent ADD COLUMN" and how it would need to
cascade to 1,000 child tables and you get the beginning of it - this
connection should not exist.
2 - INSERT/UPDATE/DELETE processing through the SQL rewrite layer (rules) is
terribly slow and gets slower as you add more partitions. If done closer to
the storage layer, this can be done in ways that use access methods shared
with other storage entities, e.g. Indices, and the code path would flow more
naturally.
3 - Parallel query can be accomplished more easily by separating scans
across relations split among tablespaces. This is more natural than trying
to parallelize APPEND nodes within existing plans
> You would need to elaborate what you actually mean, but I think it is
> moot.
> Sure, the constraint technique can be further extended (e.g. during
> runtime), but imho the approach is very good.
Well, it's being used and that's good, but it needs to be better IMO and I
think that before we go too far down the current path we should consider the
alternatives more carefully.
- Luke
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
