Re: [PATCHES] Dead Space Map version 3 (simplified)

[Hiroki Kataoka]

Gregory Stark wrote:

Hiroki Kataoka [EMAIL PROTECTED] writes:


I think there is no problem.  Bloating will make pages including the
unnecessary area which will not be accessed.  Soon, those pages will be
registered into DSM.


Except the whole point of the DSM is to let us vacuum those pages *before*
that happens...


You are right.  However, expecting perfection will often lose 
performance.  Delaying processing to some extent leads to performance.


Even if hot page is not vacuumed, it does not mean generating dead 
tuples boundlessly.  About one hot page, the quantity of dead tuple 
which continues existing unnecessarily is at most 1 page or its extent. 
 Also that page is soon registered into DSM by checkpoint like fail-safe.


Isn't some compromise need as first version of DSM vacuum?

--
Hiroki Kataoka [EMAIL PROTECTED]

---(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
  match

Re: [PATCHES] Dead Space Map version 3 (simplified)

[Hiroki Kataoka]

Heikki Linnakangas wrote:
The way you update the DSM is quite interesting. When a page is dirtied, 
the BM_DSM_DIRTY flag is set in the buffer descriptor. The corresponding 
bit in the DSM is set lazily in FlushBuffer whenever BM_DSM_DIRTY is 
set. That's a clever way to avoid contention on updates. But does it 
work for tables that have a small hot part that's updated very 
frequently?


I think there is no problem.  Bloating will make pages including the 
unnecessary area which will not be accessed.  Soon, those pages will be 
registered into DSM.


Or, though it expands however, do you assume accessing all pages equally?

--
Hiroki Kataoka [EMAIL PROTECTED]

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster