On Tue, Nov 8, 2011 at 1:07 PM, Greg Smith <g...@2ndquadrant.com> wrote: > On 11/06/2011 11:55 PM, Mark Kirkwood wrote: > > I am guessing (at this point very much guessing) that pg_freespace map may > return its data faster, as pageinspect is gonna have to grovel through all > the pages for itself (whereas pg_freespacemap relies on using info from the > ... free space map fork). > > I started with pageinspect because I wasn't sure if other methods would be > as accurate. For example, I wasn't sure until just before submission that > only the free space and size of the relation are needed to get a useful > measure here; at one point I was considering some other things too. I've > ruled them out as unnecessary as far as I can tell, but I can't claim my > tests are exhaustive. Some review confirmation that this measure is useful > for other people is one thing I was hoping for feedback on, as one thing to > consider in addition to the actual implementation. > > If this measurement is the only one needed, than as I said at the start of > the thread here it might easily be implemented to run just against the free > space map instead. I'm thinking of what's been sent so far as a UI with > matching output it should produce. If it's possible to get the same numbers > faster, exactly how to implement the function under the hood is easy enough > to change. Jaime already has a new version in development that adds a ring > buffer for example.
It's already easy to get "good enough" numbers based on user space tools with very little overhead, so I think it's more important that the server side tool be accurate rather than fast. Of course, if we can get both, that's a bonus, but I'd rather not go that route at the expense of accuracy. Just my .02. Robert Treat conjecture: xzilla.net consulting: omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
