| 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: | Whole Thread | Raw Message | 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? |