On Friday 09 March 2007 01:23, NikhilS wrote: > Hi, > > > This follows on from the suggestion I made - taken along the lines of > > the subject "auto creation of partitions" where I suggested the syntax > > of partition check(month of mydatecol) and have a new partition created > > as data was entered. With this scenario dropping the partition when it > > was empty would complement the creation of a new partition as needed. > > > > Given that there seems to be no real support of going with "auto > > maintenance" were new partitions are added as needed, then the auto > > dropping of empty partitions would also not apply. > > > > Leaving us with only specific add partition / drop partition commands. > > And have the parent table pick up rows not matching any partition check > > criteria. > > I was thinking along the lines of what Jim had suggested earlier regarding > overflow partition. Instead of dumping unmatched rows to the master table, > we could put them into a default "DUMP/DUMB" partition. >
I'm quite content dumping unmatched rows into the master table. This makes it very easy to scan partitioned tables for busted partition setups. Having a DUMP tables seems only different semantically, so why learn new semantics? > Given that Simon wants to do away with having the master table APPENDed in > the planning phase, this would be better. > ISTM you're trading appending the master table for appending the DUMP partition, which afaict would give you no gain. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match