Horton

Re: index-only scans

Jim Nasby <jim@nasby.net>

View thread
From: Jim Nasby <jim@nasby.net>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Kääriäinen Anssi <anssi.kaariainen@thl.fi>, Robert Haas <robertmhaas@gmail.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, "postgres@cybertec.at" <postgres@cybertec.at>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2011-08-15T21:53:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Reduce the alignment requirement of type "name" from int to char, and arrange

On Aug 13, 2011, at 4:31 PM, Heikki Linnakangas wrote:
>> The example is much more realistic if the query is a fetch of N latest rows from a table. Very common use case, and the whole relation's visibility statistics are completely wrong for that query.
> 
> That is somewhat compensated by the fact that tuples that are accessed more often are also more likely to be in cache. Fetching the heap tuple to check visibility is very cheap when the tuple is in cache.
> 
> I'm not sure how far that compensates it, though. I'm sure there's typically nevertheless a fairly wide range of pages that have been modified since the last vacuum, but not in cache anymore.

http://xkcd.org/937/ :)

Could something be added to pg_stats that tracks visibility map usefulness on a per-attribute basis? Perhaps another set of stats buckets that show visibility percentages for each stats bucket?
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net