| From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Strange choice of general index over partial index |
| Date: | 2015-01-16 04:00:44 |
| Message-ID: | 54B88CEC.9080009@catalyst.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2015-01-16 04:15:46 | Re: Strange choice of general index over partial index |
| Previous Message | Huan Ruan | 2015-01-16 03:32:03 | Re: shared_buffers vs Linux file cache |