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. |
=====================================================================