Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Tom Lane wrote:
>> 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.
> Hah, good one. We spent some time thinking about subtracting some value
> to make the value more accurate but it didn't occur to me to just use
> constant two.
I got the arithmetic wrong in the above, it should be like
(pg_relation_size(oid::regclass, 'fsm') -
2*current_setting('block_size')::BIGINT) / 2
With that, the runtime on HEAD's regression DB is about 700 ms, which is
still a nice win over 9000 ms.
I've put up draft wiki pages about these two problems at
https://wiki.postgresql.org/wiki/Free_Space_Map_Problems
https://wiki.postgresql.org/wiki/Visibility_Map_Problems
(thanks to Michael Paquier for initial work on the first one).
They're meant to be reasonably generic about FSM/VM problems
rather than only being about our current bugs. Please review.
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
