Re: [HACKERS] vacuum process size - Mailing list pgsql-hackers

From Brian E Gallew
Subject Re: [HACKERS] vacuum process size
Date
Msg-id emacs-smtp-447-14274-53208-353182@export.andrew.cmu.edu
Whole thread Raw
In response to Re: [HACKERS] vacuum process size  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] vacuum process size
List pgsql-hackers
Then <tgl@sss.pgh.pa.us> spoke up and said:
> So doubling the array size at each step is a good change.
> 
> But there are a lot more tuples than pages in most relations.
> 
> I see two lists with per-tuple data in vacuum.c, "vtlinks" in
> vc_scanheap and "vtmove" in vc_rpfheap, that are both being grown with
> essentially the same technique of repalloc() after every N entries.
> I'm not entirely clear on how many tuples get put into each of these
> lists, but it sure seems like in ordinary circumstances they'd be much
> bigger space hogs than any of the three VPageList lists.
> 
> I recommend going to a doubling approach for each of these lists as
> well as for VPageList.

Question: is there reliable information in pg_statistics (or other
system tables) which can be used to make a reasonable estimate for the
sizes of these structures before initial allocation?  Certainly the
file size can be gotten from a stat (some portability issues, sparse
file issues).


-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] vacuum process size
Next
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] Sorting costs (was Caution: tonight's commits force initdb)