Any idea if alter table drop column and background vacuum will be
implemented by 7.3?
It's really critical for large applications that must run 24/7.
Stephen
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister co
Added to TODO.detail/drop.
[ Charset ISO-8859-1 unsupported, converting... ]
>
> I read the transcript of the alter table drop column discussion (old
> discussion) at http://www.postgresql.org/docs/pgsql/doc/TODO.detail/drop,
> and I have something to add:
>
> People mentioned such ideas as a
I read the transcript of the alter table drop column discussion (old
discussion) at http://www.postgresql.org/docs/pgsql/doc/TODO.detail/drop,
and I have something to add:
People mentioned such ideas as a hidden column and a really deleted column,
and it occurred to me that perhaps "vacuum" woul
Zeugswetter Andreas SB wrote:
> > This style of "DROP COLUMN" would change the attribute
> > numbers whose positons are after the dropped column.
> > Unfortunately we have no mechanism to invalidate/remove
> > objects(or prepared plans) which uses such attribute numbers.
> > And I've seen no pro
> Both options are in Oracle now, as proudly documented in their
> freely accessible on-line documentation. It is very possible
> they didn't implement it until version 8, i.e. until a couple of years
> ago.
FYI: ALTER TABLE DROP COLUMN was added as of 8 / 8i according to our
Oracle DBA.
- mer
On Mon, Oct 16, 2000 at 06:51:10PM +1100, Chris wrote:
> KuroiNeko wrote:
>
> > 1 create table alpha( id int4, payload text );
>
>
> > Not a big deal, right?
>
> Yes a big deal. You just lost all your oids.
Been there. Done that. Learned to heed the warnings about using
oids in any
> > Not a big deal, right?
>
> Yes a big deal. You just lost all your oids.
After I hit the wall with oids for the first time, I don't refer to them
anymore :) But yes, you're perfectly right, this is one more reason to have
DDL completely `automated,' ie no manual substitutions.
And here th
> I think we do, because it solves more than just the ALTER DROP COLUMN
> problem: it cleans up other sore spots too. Like ALTER TABLE ADD COLUMN
> in a table with child tables.
Yes, could also implement "add column xx int before someothercolumn"
to add a column in the middle.
Andreas
At 10:56 PM 10/15/00 +0900, Hiroshi Inoue wrote:
>When I used Oracle,I saw neither option of DROP COLUMN
>feature. It seems to tell us that the implementation isn't
>that easy. It may not be a bad choise to give up DROP
>COLUMN feature forever.
Both options are in Oracle now, as proudly documen
> This style of "DROP COLUMN" would change the attribute
> numbers whose positons are after the dropped column.
> Unfortunately we have no mechanism to invalidate/remove
> objects(or prepared plans) which uses such attribute numbers.
> And I've seen no proposal/discussion to solve this problem
>
Chris wrote:
>
> Hiroshi Inoue wrote:
>
> > When I used Oracle,I saw neither option of DROP
> > COLUMN feature. It seems to tell us that the
> > implementation isn't
> > that easy. It may not be a bad choise to give up DROP
> > COLUMN feature forever.
>
> Because it's not easy we shouldn't do i
Hiroshi Inoue wrote:
> We could easily break the consistency of DB due to
> careless implementations.
I'm sure no-one around here would do careless implementations. :-)
Chris wrote:
> Hiroshi Inoue wrote:
>
> > When I used Oracle,I saw neither option of DROP
> > COLUMN feature. It seems to tell us that the
> > implementation isn't
> > that easy. It may not be a bad choise to give up DROP
> > COLUMN feature forever.
>
> Because it's not easy we shouldn't do it?
Hiroshi Inoue wrote:
> Certainly it would need 2x.
> However is ADD COLUMN DEFAULT really needed ?
> I would do as follows.
>
> ADD COLUMN (without default)
> UPDATE .. SET new_column = new default
> ALTER TABLE ALTER COLUMN SET DEFAULT
Well in current postgres that would use 2x. Wi
Chris wrote:
> Hiroshi Inoue wrote:
>
> > When I used Oracle,I saw neither option of DROP
> > COLUMN feature. It seems to tell us that the
> > implementation isn't
> > that easy. It may not be a bad choise to give up DROP
> > COLUMN feature forever.
>
> Because it's not easy we shouldn't do it?
Hiroshi Inoue wrote:
> When I used Oracle,I saw neither option of DROP
> COLUMN feature. It seems to tell us that the
> implementation isn't
> that easy. It may not be a bad choise to give up DROP
> COLUMN feature forever.
Because it's not easy we shouldn't do it? I don't think so. The perfect
KuroiNeko wrote:
> 1 create table alpha( id int4, payload text );
> Not a big deal, right?
Yes a big deal. You just lost all your oids.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> This said, I think Hiroshi's patch seems a perfect starting point, no ?
>
> > Having phantom columns adds additional complexity to the system overall.
> > We have to decide we really want it before making things more complex
> > th
KuroiNeko wrote:
> Inoue san,
>
> > This style of "DROP COLUMN" would change the attribute
> > numbers whose positons are after the dropped column.
> > Unfortunately we have no mechanism to invalidate/remove
> > objects(or prepared plans) which uses such attribute numbers.
>
> 1 create table al
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > My trial implementation using physical/logical attribute numbers
> > isn't so clean as I expected. I'm inclined to restrict my change to
> > fix the TODO
> > * ALTER TABLE A
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> My trial implementation using physical/logical attribute numbers
> isn't so clean as I expected. I'm inclined to restrict my change to
> fix the TODO
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> though it would also introdu
Inoue san,
> This style of "DROP COLUMN" would change the attribute
> numbers whose positons are after the dropped column.
> Unfortunately we have no mechanism to invalidate/remove
> objects(or prepared plans) which uses such attribute numbers.
1 create table alpha( id int4, payload text );
2
> My trial implementation using physical/logical attribute numbers
> isn't so clean as I expected. I'm inclined to restrict my change to
> fix the TODO
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> though it would also introduce a backward compatibility.
> I could live
> -Original Message-
> From: Don Baccus [mailto:[EMAIL PROTECTED]]
>
> At 04:23 PM 10/12/00 +0200, Zeugswetter Andreas SB wrote:
>
> >My conclusion would be that we need both:
> >1. a fast system table only solution with physical/logical column id
> >2. a tool that does the cleanup (e.g.
At 04:23 PM 10/12/00 +0200, Zeugswetter Andreas SB wrote:
>My conclusion would be that we need both:
>1. a fast system table only solution with physical/logical column id
>2. a tool that does the cleanup (e.g. vacuum)
Oracle provides both styles of "drop column" - the "hide the column's
data an
On Fri, 13 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > okay, but, again based on my impression of what Tom has stated, and
> > previous conversations on this topic, the key problem is what happens if I
> > drop a column and a later date decide add a new column of
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> okay, but, again based on my impression of what Tom has stated, and
> previous conversations on this topic, the key problem is what happens if I
> drop a column and a later date decide add a new column of the same name,
> what happens?
I'm not very
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> This said, I think Hiroshi's patch seems a perfect starting point, no ?
> Having phantom columns adds additional complexity to the system overall.
> We have to decide we really want it before making things more complex
> than they already are.
I think
On Fri, 13 Oct 2000, Zeugswetter Andreas SB wrote:
>
> > Hiroshi's patch would make for a good starting point by bringing in the
> > ability to do the DROP COLUMN feature, as I understand, without the
> > rollback capability,
>
> No Hiroshi's patch is rollback enabled, simply because all it doe
Tom Lane wrote:
>
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum)
>
> But the peak space usage during cleanup must still b
> Hiroshi's patch would make for a good starting point by bringing in the
> ability to do the DROP COLUMN feature, as I understand, without the
> rollback capability,
No Hiroshi's patch is rollback enabled, simply because all it does is change
some system tables. It only does not free space tha
On Fri, 13 Oct 2000, Bruce Momjian wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > we bite the bullet to the extent of supporting a distinction between
> > > physical and logical column numbers, then ISTM there's no strong need
> > > to do any of this other stuff at all. I'd exp
[ Charset ISO-8859-1 unsupported, converting... ]
> > we bite the bullet to the extent of supporting a distinction between
> > physical and logical column numbers, then ISTM there's no strong need
> > to do any of this other stuff at all. I'd expect that an inserted or
> > updated tuple would hav
> we bite the bullet to the extent of supporting a distinction between
> physical and logical column numbers, then ISTM there's no strong need
> to do any of this other stuff at all. I'd expect that an inserted or
> updated tuple would have a NULL in any physical column position that
> doesn't ha
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum)
>
> But the peak space usage during cleanup must still be 2X.
The difference for a cleanup would be, that it does not need to
On Thu, 12 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > On Thu, 12 Oct 2000, Tom Lane wrote:
> >> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> My conclusion would be that we need both:
> 1. a fast system table only solution with physical/logical
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> On Thu, 12 Oct 2000, Tom Lane wrote:
>> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
My conclusion would be that we need both:
1. a fast system table only solution with physical/logical column id
2. a tool that does the cleanup (
On Thu, 12 Oct 2000, Tom Lane wrote:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum)
>
> But the peak space usage during
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> My conclusion would be that we need both:
> 1. a fast system table only solution with physical/logical column id
> 2. a tool that does the cleanup (e.g. vacuum)
But the peak space usage during cleanup must still be 2X.
> WAL would provide the framework to do something like that, but I still
> say it'd be a bad idea. What you're describing is
> irrevocable-once-it-starts DROP COLUMN; there is no way to
> roll it back.
> We're trying to get rid of statements that act that way, not add more.
Yes.
> I am not con
> > being deleted, then if the system crashes part way through,
> it should be
> > possible to continue after the system is brought up, no?
>
> If it crashes in the middle, some rows have the column
> removed, and some
> do not.
We would need to know where this separation is, but we cannot do
The Hermit Hacker wrote:
>
> On Mon, 9 Oct 2000, Bruce Momjian wrote:
>
> Ya, but in one email, you appear to agree with me ... then Tom posts a
> good point and you jump over to that side ... at least pick a side? :) I
> too wish to see it implemented, I just don't want to have to double my
>
At 07:55 PM 10/9/00 -0300, The Hermit Hacker wrote:
>> I am not convinced that a 2x penalty for DROP COLUMN is such a huge
>> problem that we should give up all the normal safety features of SQL
>> in order to avoid it. Seems to me that DROP COLUMN is only a big
>> issue during DB development, w
> > > > > I am not convinced that a 2x penalty for DROP COLUMN is such a huge
> > > > > problem that we should give up all the normal safety features of SQL
> > > > > in order to avoid it. Seems to me that DROP COLUMN is only a big issue
> > > > > during DB development, when you're usually workin
On Mon, 9 Oct 2000, Bruce Momjian wrote:
> > On Mon, 9 Oct 2000, Bruce Momjian wrote:
> >
> > > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > > hrmm .. mvcc uses a timestamp, no? is there no way of using that
> > > > > timestamp to determine which columns have/haven't been cleaned up
> On Mon, 9 Oct 2000, Bruce Momjian wrote:
>
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > hrmm .. mvcc uses a timestamp, no? is there no way of using that
> > > > timestamp to determine which columns have/haven't been cleaned up
> > > > following a crash? maybe some way of markin
On Mon, 9 Oct 2000, Bruce Momjian wrote:
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > hrmm .. mvcc uses a timestamp, no? is there no way of using that
> > > timestamp to determine which columns have/haven't been cleaned up
> > > following a crash? maybe some way of marking a table as
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > hrmm .. mvcc uses a timestamp, no? is there no way of using that
> > timestamp to determine which columns have/haven't been cleaned up
> > following a crash? maybe some way of marking a table as being in a 'drop
> > column' mode, so that when i
On Mon, 9 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > hrmm .. mvcc uses a timestamp, no? is there no way of using that
> > timestamp to determine which columns have/haven't been cleaned up
> > following a crash? maybe some way of marking a table as being in a '
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> hrmm .. mvcc uses a timestamp, no? is there no way of using that
> timestamp to determine which columns have/haven't been cleaned up
> following a crash? maybe some way of marking a table as being in a 'drop
> column' mode, so that when it gets bro
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> It is not. The only downside is 2x disk space to make new versions of
>> the tuple.
> huh? vacuum moves/cleans up tuples, as well as compresses them, so that
> the end result is a smaller table then what it started with, at/with very
> little inc
On Mon, 9 Oct 2000, Bruce Momjian wrote:
> > > > Sorry, that's what I meant ... why should marking a column as 'deleted'
> > > > and running a 'vacuum' to clean up the physical table be any less
> > > > crash-safe?
> > >
> > > It is not. The only downside is 2x disk space to make new versions
> > > Sorry, that's what I meant ... why should marking a column as 'deleted'
> > > and running a 'vacuum' to clean up the physical table be any less
> > > crash-safe?
> >
> > It is not. The only downside is 2x disk space to make new versions of
> > the tuple.
>
> huh? vacuum moves/cleans up
On Mon, 9 Oct 2000, Bruce Momjian wrote:
> > On Mon, 9 Oct 2000, Tom Lane wrote:
> >
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > >> What happens if you crash partway through?
> > >
> > > > what happens if you crash partway through a vacuum?
> > >
> > > Nothing. Vacuum is crash-s
> On Mon, 9 Oct 2000, Tom Lane wrote:
>
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > >> What happens if you crash partway through?
> >
> > > what happens if you crash partway through a vacuum?
> >
> > Nothing. Vacuum is crash-safe. ALTER TABLE should be too.
>
> Sorry, that's what I
On Mon, 9 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> >> What happens if you crash partway through?
>
> > what happens if you crash partway through a vacuum?
>
> Nothing. Vacuum is crash-safe. ALTER TABLE should be too.
Sorry, that's what I meant ... why shoul
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> What happens if you crash partway through?
> what happens if you crash partway through a vacuum?
Nothing. Vacuum is crash-safe. ALTER TABLE should be too.
regards, tom lane
On Mon, 9 Oct 2000, Bruce Momjian wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >> Basically, move the first 100 rows to the end of the table file, then take
> > >> 100 and write it to position 0, 101 to position 1, etc ... that way, at
> > >> max, you are using ( tuple * 100 ) bytes o
On Mon, 9 Oct 2000, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Basically, move the first 100 rows to the end of the table file, then take
> >> 100 and write it to position 0, 101 to position 1, etc ... that way, at
> >> max, you are using ( tuple * 100 ) bytes of disk space,
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Basically, move the first 100 rows to the end of the table file, then take
> >> 100 and write it to position 0, 101 to position 1, etc ... that way, at
> >> max, you are using ( tuple * 100 ) bytes of disk space, vs 2x the table
> >> size ... either
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Basically, move the first 100 rows to the end of the table file, then take
>> 100 and write it to position 0, 101 to position 1, etc ... that way, at
>> max, you are using ( tuple * 100 ) bytes of disk space, vs 2x the table
>> size ... either method is
> Basically, move the first 100 rows to the end of the table file, then take
> 100 and write it to position 0, 101 to position 1, etc ... that way, at
> max, you are using ( tuple * 100 ) bytes of disk space, vs 2x the table
> size ... either method is going to lock the file for a period of time,
On Thu, 5 Oct 2000, Tom Lane wrote:
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Seems some people expect the implementation in 7.1.
> > (recent [GENERAL} drop column?)
> > I could commit my local branch if people don't mind
> > backward incompatibility.
there have been several ideas thrown
seconded ...
On Fri, 29 Sep 2000, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, I am opening this can of worms again. I personally would like to
> > see this code activated, even if it does take 2x the disk space to alter
> > a column. Hiroshi had other ideas. Where did
At 12:05 6/10/00 +0900, Hiroshi Inoue wrote:
>
>Tom Lane wrote:
>
>> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> P.S. I've noticed that get_rte_attribute_name() seems to
>> break my implementation. I'm not sure if I could solve it.
>> >>
>> >> That would be a problem --- rule dumping de
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> P.S. I've noticed that get_rte_attribute_name() seems to
> break my implementation. I'm not sure if I could solve it.
> >>
> >> That would be a problem --- rule dumping depends on that code to
> >> produce correct aliases, s
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
P.S. I've noticed that get_rte_attribute_name() seems to
break my implementation. I'm not sure if I could solve it.
>>
>> That would be a problem --- rule dumping depends on that code to
>> produce correct aliases, so making it work is not optio
Tom Lane wrote:
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Seems some people expect the implementation in 7.1.
> > (recent [GENERAL} drop column?)
> > I could commit my local branch if people don't mind
> > backward incompatibility.
>
> I've lost track --- is this different from the _DROP
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Seems some people expect the implementation in 7.1.
> (recent [GENERAL} drop column?)
> I could commit my local branch if people don't mind
> backward incompatibility.
I've lost track --- is this different from the _DROP_COLUMN_HACK__
code that's alre
> -Original Message-
> From: Tom Lane
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, I am opening this can of worms again. I personally would like to
> > see this code activated, even if it does take 2x the disk space to alter
> > a column. Hiroshi had other ideas. Where did we le
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, I am opening this can of worms again. I personally would like to
> see this code activated, even if it does take 2x the disk space to alter
> a column. Hiroshi had other ideas. Where did we leave this? We have
> one month to decide on a plan.
I
OK, I am opening this can of worms again. I personally would like to
see this code activated, even if it does take 2x the disk space to alter
a column. Hiroshi had other ideas. Where did we leave this? We have
one month to decide on a plan.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > You
72 matches
Mail list logo
