-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Big bloat discrepencies compared to pgstattuple #24
Comments
Hi, Either your stats are wrong, or you have a lot of toasted values... Unfortunately, columns size stats reports the size of the pointer itself when a value is toasted away and the query doesn't deal with this :/ See: https://github.com/ioguix/pgsql-bloat-estimation#toasted-fields |
let me investigate the toast side of things and get back with you, thanks for the feedback! |
I am not able to reproduce the situation anymore, so let's close this issue as a non-issue |
I am re-opening this since I have an example to work with again. Will be updating this shortly... |
I have logically (pg_dump/pg_restore) copied a table from one database to another, vsked_analysis. So now I can see what a completely unbloated table looks like in the target db. Both tables have the same amount of rows. There are 13 indexes on the table including the primary key. Both were vacuumed and analyzed right before gathering these stats. My general observations are that your query is pretty good especially on the non-bloated table, but like pgstattuple, it underestimates the bloat significantly on the source, bloated table. I was wondering if you could provide any insight based on the following captured metrics. SELECT pg_size_pretty(pg_total_relation_size('public.vsked_analysis'));
I also ran pgstattuple on both the regular table and the toast table for them:
Your table query:
In the source:
|
Using the table bloat checker here I get this on my database (PG 14):
But with pgstattuple I get this:
SELECT tuple_percent, dead_tuple_percent, free_percent FROM pgstattuple('cc_merge.ccx_ex_contactdrpservices');
Why the big discrepency?
The text was updated successfully, but these errors were encountered: