On 4/24/15 6:52 AM, Robert Haas wrote:
On Thu, Apr 23, 2015 at 9:03 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
On Thu, Apr 23, 2015 at 10:42 PM, Robert Haas wrote:
On Thu, Apr 23, 2015 at 4:19 AM, Simon Riggs wrote:
We only need a freeze/backup map for larger relations. So if we map 1000
blocks per map page, we skip having a map at all when size < 1000.
Agreed. We might also want to map multiple blocks per map slot - e.g.
one slot per 32 blocks. That would keep the map quite small even for
very large relations, and would not compromise efficiency that much
since reading 256kB sequentially probably takes only a little longer
than reading 8kB.
I think the idea of integrating the freeze map into the VM fork is
also worth considering. Then, the incremental backup map could be
optional; if you don't want incremental backup, you can shut it off
and have less overhead.
When I read that I think about something configurable at
relation-level.There are cases where you may want to have more
granularity of this information at block level by having the VM slots
to track less blocks than 32, and vice-versa.
What are those cases? To me that sounds like making things
complicated to no obvious benefit.
Tables that get few/no dead tuples, like bulk insert tables. You'll have
large sections of blocks with the same visibility.
I suspect the added code to allow setting 1 bit for multiple pages
without having to lock all those pages simultaneously will probably
outweigh making this a reloption anyway.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
