On Tue, Jan 08, 2008 at 02:12:28AM +0000, Gregory Stark wrote: > > 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.
Probably in that one, yes. I'm still waiting for permission to post my original problem statement; I suspect it's not going to be forthcoming by next Monday, so it's not going to happen. But I did outline something like what I'm talking about elsewhere in this thread. For my case, I'm thinking of the sort of data that builds up over time, and most of which happens probably not to be useful at any moment, but all of which _might_ be useful over the long haul. So what I wanted, originally, was to be able to set arbitrary ranges of tuples to be read-only, and to be able to set them offline if I wanted. Pseudo-DDL: ALTER TABLE foo SET read_only='t' WHERE created_on < '2007-01-01'; ALTER TABLE foo SET tuple_offline='t' WHERE created_on < '2006-01-01'; Now, the second segment is marked "offline". If I query the table for things in that range, I get an ERROR telling me there might be data in the range, but it's not mounted at the moment. If I try to update records in the read-only (first) range, I get an error telling me the tuple is marked read only. The idea then is that these older tuples can be put off into long-term storage (wave hands here about the management of that stuff), and this keeps my online system compact but yet allows me, for just the cost of mounting a backup tape and reading the segments back, to go back and query those old ranges. The case I was particularly aiming at originally was for a case of data that cannot cost more than fractions of pennies to store, but that might represent a hugely expensive liability if the answer is not always right. Driving down that storage cost was mostly what I was aiming at, but people gradually convinced me that slightly more generic implementations might be useful. Simon's proposal came along, and it seems to me to be something like the generic implementation that others already convinced me was needed. > 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 don't see how that's the case at all. In fact, I have the feeling it's the opposite, so perhaps I've misunderstood something. A ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org