"Andrew Sullivan" <[EMAIL PROTECTED]> writes: > On Mon, Jan 07, 2008 at 07:16:35PM +0100, Markus Schiltknecht wrote: >> >> Does anything speak against letting the DBA handle partitions as relations? > > Yes: it doesn't solve the problem I have, which is that I don't want to have > to manage a whole bunch of tables. I want one table, and I want to be able > to say, "That section is closed".
That's not your problem, that's the solution you're looking for. You're assuming a particular solution in your problem statement. I posit that the whole point of partitioning is to create an object which serves to represent the semantically meaningful chunks of data. The reason this is useful is precisely because it serves as a short-hand for the DBA describe the data and how it will be used. I think Simon's proposal loses the very feature that makes partitioning useful. The DBA doesn't have a "thing" to describe, he has to define what parts of the table he's describing for every operation. And if you define a whole new object to name these "things" I think you'll end up with something that looks a lot like tables. I also don't understand how this proposal deals with the more common use case of unloading and loading data. Normally in partitioned tables we build the data in a side table until the data is all correct then load it as a partition. If you treat it as a lower-level object then I don't see that working. The layout of the new table won't often match the layout of the target partitioned table. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---------------------------(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
