Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> But then what happens when you want to update a second tuple on the same
> >> page?  None of our existing plan types release and reacquire pin if they
> >> don't have to, and I really doubt that we want to give up that
> >> optimization.
> > You will prune when you lock the page and at that point unless you got
> > enough room for both tuples I doubt trying just before the second tuple
> > is going to help.
> No, you're missing the point completely.  If the free space on the page
> is, say, 1.5x the average tuple size, the code *won't* prune, and then
> it will be stuck when it goes to do the second tuple update, because
> there is no chance to reconsider the prune/no-prune decision after some
> space is eaten by the first update.

My point is that if you only do this for INSERT/UPDATE, you can prune
when you have less than enough room for 3-4 tuples, and if you add the
xmin of the earliest prune xact you can prune even more aggressively.

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to