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
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"
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
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
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
than they
KuroiNeko wrote:
1 create table alpha( id int4, payload text );
snip
Not a big deal, right?
Yes a big deal. You just lost all your oids.
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. With WAL
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? I don't think
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
for
-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. vacuum)
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
-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 ADD COLUMN to
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 have
[ 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 have a
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 expect that
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 that
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 does is
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 we
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
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
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 a
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 cleanup
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
disk
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 being
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
following a
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 working with relatively
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, when
-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 leave this?
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 can
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 think
30 matches
Mail list logo
