Re: Plans for solving the VACUUM problem

Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
>> The comment says
>>
>> ** Take a compressed entry, and install it on a page. Since we now know
>> ** where the entry will live, we decompress it and recompress it using
>> ** that knowledge (some compression routines may want to fish around
>> ** on the page, for example, or do something special for leaf nodes.)
>>
>> Are you prepared to say that you will no longer support the ability for
>> GIST compression routines to do those things? That seems shortsighted.

> No-no !!! we don't intend to lose that (compression) functionality.

> there are several reason we want to eliminate gistPageAddItem:
> 1. It seems there are no examples where compress uses information about
> the page.

We have none now, perhaps, but the original GIST authors seemed to think
it would be a useful capability. I'm hesitant to rip out functionality
that they put in --- I don't think we understand GIST better than they
did ;-)

> 2. There is some discrepancy between calculation of free space on page and
> the size of tuple saved on page - calculation of free space on page
> by gistNoSpace uses compressed tuple but tuple itself saved after
> recompression. It's possible that size of tupple could changed
> after recompression.

Yes, that's a serious problem with the idea. We'd have to suppose that
recompression could not increase the size of the tuple --- or else be
prepared to back up and find another page and do it again (ugh).

> 3. decompress/compress could slowdown insert because it happens
> for every tuple.

Seems like there should be a flag somewhere that tells whether the
compression function actually cares about the page context or not.
If not, you could skip the useless processing.

> 4. Currently gistPageAddItem is broken because it's not toast safe
> (see call gist_tuple_replacekey in gistPageAddItem)

Not sure I see the problem. gist_tuple_replacekey is kinda ugly, but
what's it got to do with TOAST?

regards, tom lane