Re: Why a bitmap scan in this case?

From: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
To: Jon Zeppieri <zeppieri(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Why a bitmap scan in this case?
Date: 2024-12-20 09:57:40
Message-ID: 8038b7ca-d4ba-40fb-824b-5f984fb80612@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 12/20/24 09:16, Frédéric Yhuel wrote:
>
>
> On 12/19/24 20:09, Jon Zeppieri wrote:
>> The table is freshly vacuumed. If I disable bitmap scans, it will do
>> an index only scan, which performs better. For the bitmap heap scan,
>> it says "Heap Blocks: exact=27393," whereas for the index only scan,
>> it's "Heap Fetches: 27701."
>
> So you have 100% heap fetches. Are you sure that your table is freshly
> vacuumed? Please note that VACUUM FULL doesn't create the visibility
> map, so you still have to run a plain VACUUM for this.
>
>

And if you still have heap fetches, you could try VACUUM (INDEX_CLEANUP
TRUE), so that it doesn't bypass index vacuuming.

(In case the pages that contain theses 27701 tuples amount to less than
2% of the total number of pages of the table).

Nice explanation here:
https://www.cybertec-postgresql.com/en/making-the-postgresql-visibility-map-visible/#vacuum-doesnt-update-the-visibility-map-as-it-should

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Pavel Stehule 2024-12-20 12:53:20 Re: proposal: schema variables
Previous Message Frédéric Yhuel 2024-12-20 08:16:48 Re: Why a bitmap scan in this case?