Re: RFC: Restructuring pg_aggregate

Christopher Kings-Lynne wrote:
> > 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.

OK, let me mention that I have had great success with chat sessions with
PostgreSQL developers. They can code and ask questions and I can answer
quickly. Seems to be speeding things along for some people. I am:

AIM bmomjian
ICQ 151255111
Yahoo bmomjian
MSN root(at)candle(dot)pha(dot)pa(dot)us

I am also on the PostgreSQL IRC channel. As far as where to start, I
think the CLUSTER command would be a good start because it just reorders
the existing table. Then DROP COLUMN can come out of that by removing
the column during the copy, and removing mention of the column from
pg_attribute, and of course renumbering the gap.

> > 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?

Not really. I moves only whole tuples, and only certain ones.

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

No, not in libpq, but rather in backend/libpq, the backend part of the
connection. My idea is for the user to think things are in a different
order in the row than they actually appear on disk. I haven't really
researched it enough to understand its validity.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026