I wrote:
> It looks to me like this is approximating the highest block number that
> could possibly have an FSM entry as size of the FSM fork (in bytes)
> divided by 2. But the FSM stores one byte per block. There is overhead
> for the FSM search tree, but in a large relation it's not going to be as
> much as a factor of 2. So I think that to be conservative we need to
> drop the "/ 2". Am I missing something?
Ah, scratch that, after rereading the FSM README I see it's correct,
because there's a binary tree within each page; I'd only remembered
that there was a search tree of pages.
Also, we could at least discount the FSM root page and first intermediate
page, no? That is, the upper limit could be
pg_relation_size(oid::regclass, 'fsm') / 2 -
2*current_setting('block_size')::BIGINT
I think this is a worthwhile improvement because it reduces the time spent
on small relations. For me, the query as given takes 9 seconds to examine
the regression database, which seems like a lot. Discounting two pages
reduces that to 20 ms.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
