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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers