On 16/01/15 16:28, Josh Berkus wrote:
On 01/16/2015 04:17 PM, Mark Kirkwood wrote:
On 16/01/15 16:06, Mark Kirkwood wrote:
A bit more poking about shows that the major factor (which this fake
dataset anyway) is the default for effective_cache_size (changes from
128MB to 4GB in 9.4). Increasing this makes 9.2 start using the
files_in_flight index in a plain index scan too.
Arrg - misread the planner output....in 9.2 what changes is a plan that
uses an index scan on the *file_state* index (not
files_in_flight)...which appears much faster than the bitmap scan on
file_state. Apologies for the confusion.
I'm thinking that I'm seeing the effect Tom has just mentioned.
It's not using a bitmapscan in either case; it's a straight indexscan.
Right, I suspect that bloating is possibly the significant factor then -
can you REINDEX?
Cheers
Mark
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
