Re: Plans for solving the VACUUM problem - Mailing list pgsql-hackers
From | Oleg Bartunov |
---|---|
Subject | Re: Plans for solving the VACUUM problem |
Date | |
Msg-id | Pine.GSO.4.33.0105182118490.12431-100000@ra.sai.msu.su Whole thread Raw |
In response to | Plans for solving the VACUUM problem (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On Fri, 18 May 2001, Tom Lane wrote: > Oleg Bartunov <oleg@sai.msu.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 ;-) ok. we save the code for future. Probably we could ask original author btw, who is the orig, author (Hellerstein, Aoki) ? > > > 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). > We have to keep in mind this when return to gistPageAddItem. > > 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. > ok. see above. > > 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? > tuple could be formed not by index_formtuple which is a correct way. > regards, tom lane > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
pgsql-hackers by date: