On Mar 6, 2007, at 9:13 AM, Shane Ambler wrote:
NikhilS wrote:
On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
1) Whether we should use triggers/rules for step number (iii) above.
> Maybe rules is the way to go.
Since this would basically be a case of the updatable rules
problem, you
should review those discussions in the past to check whether the
issues
mentioned there don't interfere with that plan.
The rules mentioned here will be to specify that all the
inserts/updates/deletes should go into proper children tables
instead of the
parent. I do not see the updateable rules problem with regards to
this, but
will check out the archives for discussion on this related to
partitioning.
I would think that a trigger would be a better choice as I see the
need (or at least the possibility) for more than just a rewrite.
When a value is inserted that is outside of a condition currently
covered by an existing child table then a new child will need to be
spawned to contain the new data.
There's no reason a new child has to be spawned, and I don't think
that having a DML statement 'automagically' generating DDL is such a
hot idea, either.
Also, there's nothing inherently wrong with having an 'overflow
partition' (to use Oracle syntax) that holds values that don't fall
in the range of any other tables. The obvious place to do that with
our partitioning is in the parent table.
There are 2 other reasons to favor triggers though:
1) People (Josh Drake comes to mind) have found that if you get over
a tiny number of partitions, the performance of rules is abysmal.
2) I believe it should be possible to construct an update trigger
that allows you to perform updates that will place the row in
question into a new partition. While I can see cases for simply
disallowing updates to the partitioning key, I think there are also
times when being able to do that would be very useful.
Will ALTER TABLE be extended to handle partitions? This will allow
partitioning existing tables (maybe without blocking access?) and
allow things like ALTER TABLE mytable ADD PARTITION (mydate within
200703)
and ALTER TABLE mytable DROP PARTITION (mydate within 199912) or
would dropping be covered by DELETE FROM mytable where mydate <=
199912 ?
I think it'd be great to make adding and removing partitions as
simple as ALTER TABLE. I don't think that DELETE should be the
mechanism to drop a partition, though. Again, DML statements
shouldn't be performing DDL.
Could such a syntax be devised for date columns? (month of mydate)
or similar to auto create partitions based on the year and month of
a date column? or will we just do CHECK(mydatecol >= 1/3/07 and
mydatecol <= 31/3/07) for each month of data? Also (day of
mydatecol) to partition based on year and day of year.
Another syntax possibility - range(myserialcol of 500000) where new
child tables are created every 500000 rows?
Maybe I'm looking at auto-maintenance which is beyond any current
planning?
I don't think it's worth it to burden the database with auto-creating
time partitions; it's easy enough to setup a cron job to handle it.
It might be more useful to have the database handle things like
partitioning on a SERIAL column, though I agree with Nikhils that
this should wait.
Does any other database support 'automagic' partition creation? I
know Oracle 9i doesn't... not sure about 10g or DB2 or MSSQL...
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
