From: | Jesper Krogh <jesper(at)krogh(dot)cc> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: crash-safe visibility map, take three |
Date: | 2011-01-06 07:00:29 |
Message-ID: | 4D25688D.2010706@krogh.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2011-01-06 03:10, Robert Haas wrote:
> On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh<jesper(at)krogh(dot)cc> wrote:
>> Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit
>> serve?
> If we modify a page on which PD_ALL_VISIBLE isn't set, we don't
> attempt to update the visibility map. In theory, this is an important
> optimization to reduce contention on the visibility map page, since
> there are something like 64K heap pages per visibility map page. In
> practice, I'm not sure in what workloads it matters or by how much
If that is the only reason, I would suggest just making the visibillity map
pages more sparse. If you just had 500 or 1K heap pages per visibillity map
page, then it would not change a thing for the performance. With 1K heap
pages
per VM map page a relation with 100GB of data would have a VM map of
the VM map of 100MB, even 100 heap pages per VM-map page would still
enable the database to have visibillity information of 100GB data stored
in 1GB
of memory.
But it would need testing and benchmarking to find out.
Jesper
--
Jesper
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-01-06 08:19:55 | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED |
Previous Message | KaiGai Kohei | 2011-01-06 06:30:11 | Re: sepgsql contrib module |