Re: Bitmap Heap scan 8.1/8.2

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Martin Marques <martin(at)bugs(dot)unl(dot)edu(dot)ar>, pgsql-general(at)postgresql(dot)org
Subject: Re: Bitmap Heap scan 8.1/8.2
Date: 2007-10-22 20:47:10
Message-ID: 471D0C4E.1040308@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


> 2007/10/22, Martin Marques <martin(at)bugs(dot)unl(dot)edu(dot)ar>:
>> Pavel Stehule wrote:
>>> Hello
>>>
>>> I am unsure, did you check config values?
>> Don't know which ones you are talking about, but all enable_* are set to on.
>>
>> Anything else?
>>
>
> shared_buffers
> work_mem
> effective_cache_size
>
> Pavel

Well, the cost_* values might be interesting too. That is

seq_page_cost
random_page_cost
cpu_tuple_cost
cpu_index_tuple_cost
cpu_operator_cost
effective_cache_size

(the first one is available in 8.2 only). My guess is that there are
different values, and the 8.2 overestimates the index scan - which seems
to be incorrect.

Try to disable the seqscan in the 8.2 database (set enable_seqscan =
off), and run the explain analyze again. This time it should choose
different query plan - maybe the index scan as in 8.1.

Another thing you might try is setting the cost values to the same
values in both databases - it might help.

And what does it mean by 'same data' - have you vacuumed / analyzed both
of them? What does this return:

select relname, relpages, reltuples from pg_class where relname =
'prestamos' or relname='prestamos_objetos_devuelto_idx';

That should return number of tuples / occupied pages in the table and index.

Tomas

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Browne 2007-10-22 20:59:40 Re: How to use 'toast'
Previous Message Magnus Hagander 2007-10-22 20:45:02 Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit