|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: FSM corruption leading to errors|
|Views:||Raw Message | Whole Thread | Download mbox|
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
(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
|Next Message||Robert Haas||2016-10-24 18:49:00||Re: Press Release Draft - 2016-10-27 Cumulative Update|
|Previous Message||Alvaro Herrera||2016-10-24 18:31:03||Re: [COMMITTERS] pgsql: Remove extra comma at end of enum list|