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
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? |