Re: RFC: Restructuring pg_aggregate

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Restructuring pg_aggregate
Date: 2002-04-11 04:30:08
Message-ID: GNELIHDDFBOCMGBFGEFOOEBGCCAA.chriskl@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Actually, what we need to do to reclaim space is to enable table
> recreation without the column, now that we have relfilenode for file
> renaming. It isn't hard to do, but no one has focused on it. I want to
> focus on it, but have not had the time, obviously, and would be very
> excited to assist someone else.

I'm happy to help - depends if it's within my skill level or not tho. Most
of the time the problem I have is finding where to make the changes, not
actually making the changes themselves. So, count me in.

> Hiroshi's fine idea of marking certain columns as unused would not have
> reclaimed the missing space, just as my idea of physical/logical column
> distinction would not reclaim the space either. Again, my
> physical/logical idea is more for fixing other problems and
> optimization, not DROP COLUMN.

Question: Is it _possible_ to reclaim the space during a VACUUM FULL? I do
not know enough about the file format to know this. What happens if the
VACUUM is stopped halfway thru reclaiming a column in a table?

Bruce: WRT modifying libpq to do the translation - won't this cause probs
for JDBC and ODBC people?

Chris

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-11 04:33:39 Re: help with bison
Previous Message Bruce Momjian 2002-04-11 04:19:08 Re: RFC: Restructuring pg_aggregate