Re: Measuring relation free space
Jaime Casanova <jaime@2ndquadrant.com>
From: Jaime Casanova <jaime@2ndquadrant.com>
To: Noah Misch <noah@leadboat.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Bernd Helmle <mailings@oopsware.de>, Greg Smith <greg@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-14T07:04:26Z
Lists: pgsql-hackers
Attachments
- pgstattuple-gin_spgist.patch (text/x-patch) patch
- pgstattuple-relation_free_space.patch (text/x-patch) patch
- pgstattuple-stats_target.patch (text/x-patch) patch
On Wed, Jan 25, 2012 at 9:47 PM, Noah Misch <noah@leadboat.com> wrote: > > With all that done, run some quick benchmarks: see how "SELECT free_percent > FROM pgstattuple(rel)" fares compared to "SELECT relation_free_space(rel)" for > a large heap and for a large B-tree index. If the timing difference is too > small to be interesting to you, remove relation_free_space() and submit your > pgstattuple() improvements alone. Otherwise, submit as written. > Ok. I split this in three patches. 1) pgstattuple-gin_spgist.patch This first patch adds gin and spgist support to pgstattuple, also makes pgstattuple use a ring buffer when reading tables or indexes. 2) pgstattuple-relation_free_space.patch This patch adds the relation_free_space function to pgstattuple. the function relation_free_space() is faster than pgstattuple(), to test that i initialize pgbench with a scale of 40. In that context pgstattuple() tooks 1.4s to process pgbench_account table and relation_free_space() tooks 730ms (half the time!) In the index the difference is less notorious, 170ms the former and 150ms the latter. 3) pgstattuple-stats_target.patch This patch adds a stats_target parameter to the relation_free_space() function, it mimics the way analyze choose the blocks to read and is faster than plain relation_free_space() but of course could be inexact if the pages that we don't read are the ones with more free space -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación