čt 6. 12. 2018 v 17:02 odesílatel Robert Haas <robertmh...@gmail.com> napsal:
> On Thu, Dec 6, 2018 at 10:53 AM Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > čt 6. 12. 2018 v 16:26 odesílatel Robert Haas <robertmh...@gmail.com> > napsal: > >> On Thu, Dec 6, 2018 at 10:23 AM Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> > I have a problem to imagine it. When fill factor will be low, then > there is high risk of high fragmentation - or there some body should to do > defragmentation. > >> > >> I don't understand this. > > > > I don't know if zheap has or has not any tools for elimination > fragmentation of space of page. But I expect so after some set of updates, > when record size is mutable, the free space on page should be fragmented. > Usually, when you have less memory, then fragmentation is faster. > > Still not sure I completely understand, but it's true that zheap > sometimes needs to compact free space on a page. For example, if > you've got a page with a 100-byte hole, and somebody updates a tuple > to make it 2 bytes bigger, you've got to shift that tuple and any that > precede it backwards to reduce the size of the hole to 98 bytes, so > that you can fit the new version of the tuple. If, later, somebody > shrinks that tuple back to the original size, you've now got 100 bytes > of free space on the page, but they are fragmented: 98 bytes in the > "hole," and 2 bytes following the newly-shrunk tuple. If someone > tries to insert a 100-byte tuple in that page, we'll need to > reorganize the page a second time to bring all that free space back > together in a single chunk. > > In my view, and I'm not sure if this is how the code currently works, > we should have just one routine to do a zheap page reorganization > which can cope with all possible scenarios. I imagine that you would > give it the page is it currently exists plus a "minimum tuple size" > for one or more tuples on the page (which must not be smaller than the > current size of that tuple, but could be bigger). It then reorganizes > the page so that every tuple for which a minimum size was given > consumes exactly that amount of space, every other tuple consumes the > minimum possible amount of space, and the remaining space goes into > the hole. So if you call this function with no minimal tuple sizes, > it does a straight defragmentation; if you give it minimum tuple > sizes, then it rearranges the page to make it suitable for a pending > in-place update of those tuples. > > Actually, I think Amit and I discussed further refining this by > splitting the page reorganization function in half. One half would > make a plan for where to put each tuple on the page following the > reorg, but would not actually do anything. That would be executed > before entering a critical section, and might fail if the requested > minimum tuple sizes can't be satisfied. The other half would take the > previously-constructed plan as input and perform the reorganization. > That would be done in the critical section. > > Thank you for reply Pavel -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
