Обсуждение: Reduce the size of PageFreeSpaceInfo on 64bit platform

Here is a patch to reduce the size of PageFreeSpaceInfo on 64bit platform.
We will utilize maintenance_work_mem twice with the patch.

The sizeof(PageFreeSpaceInfo) is 16 bytes there because the type of 'avail'
is 'Size', that is typically 8 bytes and needs to be aligned in 8-byte bounds.
I changed the type of the field to uint32. We can store the freespace with
uint16 at smallest, but the alignment issue throws it away.

If we need to store freespace more compactly rather than calculation speed,
it might be good to use FSMPageData instead of PageFreeSpaceInfo, but I did
not change it in this patch.


Index: src/include/storage/freespace.h
===================================================================
--- src/include/storage/freespace.h    (head)
+++ src/include/storage/freespace.h    (fixed)
@@ -24,7 +24,7 @@
 typedef struct PageFreeSpaceInfo
 {
     BlockNumber blkno;            /* which page in relation */
-    Size        avail;            /* space available on this page */
+    uint32        avail;            /* space available on this page */
 } PageFreeSpaceInfo;


----

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> -    Size        avail;            /* space available on this page */
> +    uint32        avail;            /* space available on this page */

This declaration ties into a boatload of others, eg, just about every
use of Size in freespace.h.  I'm unconvinced that we need to change it,
but if we do, the patch needs to be a lot bigger.

            regards, tom lane

On Fri, Aug 10, 2007 at 10:32:35AM +0900, ITAGAKI Takahiro wrote:
> Here is a patch to reduce the size of PageFreeSpaceInfo on 64bit platform.
> We will utilize maintenance_work_mem twice with the patch.
>
> The sizeof(PageFreeSpaceInfo) is 16 bytes there because the type of 'avail'
> is 'Size', that is typically 8 bytes and needs to be aligned in 8-byte bounds.
> I changed the type of the field to uint32. We can store the freespace with
> uint16 at smallest, but the alignment issue throws it away.

So... does that mean that the comment in the config file about 6 bytes
per page is incorrect?
--
Decibel!, aka Jim Nasby                        decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Decibel! <decibel@decibel.org> wrote:

> > The sizeof(PageFreeSpaceInfo) is 16 bytes

> So... does that mean that the comment in the config file about 6 bytes
> per page is incorrect?

There are no comments the usage of maintenance_work_mem in the config file
nor the documentation. Memory consumed by max_fsm_pages is only mentioned.

#maintenance_work_mem = 16MB # min 1MB
#max_fsm_pages = 204800      # min max_fsm_relations*16, 6 bytes each


But surely the difference of memory usage between maintenance_work_mem
and max_fsm_pages might confuse users. I'll rewrite my patch to use
FSMPageData in both places so that users can always estimate the memory
to 6 bytes per page.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

I wrote:

> I'll rewrite my patch to use
> FSMPageData in both places so that users can always estimate the memory
> to 6 bytes per page.

Here is a revised patch to reduce memory usage during VACUUM,
using FSMPageData (6 byte) instead of PageFreeSpaceInfo (8 or 16 bytes).
The keepable pages with freespace will extended to 21GB from 8GB with
16MB of default maintenance_work_mem.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

This has been saved for the 8.4 release:

    http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

ITAGAKI Takahiro wrote:
> I wrote:
>
> > I'll rewrite my patch to use
> > FSMPageData in both places so that users can always estimate the memory
> > to 6 bytes per page.
>
> Here is a revised patch to reduce memory usage during VACUUM,
> using FSMPageData (6 byte) instead of PageFreeSpaceInfo (8 or 16 bytes).
> The keepable pages with freespace will extended to 21GB from 8GB with
> 16MB of default maintenance_work_mem.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>

[ Attachment, skipping... ]

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

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> Here is a revised patch to reduce memory usage during VACUUM,
> using FSMPageData (6 byte) instead of PageFreeSpaceInfo (8 or 16 bytes).

Applied, thanks.

> The keepable pages with freespace will extended to 21GB from 8GB with
> 16MB of default maintenance_work_mem.

AFAICS, maintenance_work_mem doesn't really have anything to do with
this; but it should reduce memory usage anyway if you've got large
relations and a large max_fsm_pages setting.

I'm a bit worried that the change may be pointless if FSM is rewritten
to not use dedicated shared memory, as I hope will happen for 8.4.
But we can always revert it if that happens.

            regards, tom lane