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 fooSET read_only='t'WHERE created_on < '2007-01-01';ALTER TABLE fooSET 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