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
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
32 matches
Mail list logo
