Jan Urbański wrote:
Not good... Shall I try sorting pg_statistics arrays on text values instead of frequencies?
Yeah, I'd go with that. If you only do it for the new STATISTIC_KIND_MCV_ELEMENT statistics, you shouldn't need to change any other code.
Hmm. There has been discussion on raising default_statistic_target, and one reason why we've been afraid to do so has been that it increases the cost of planning (there's some O(n^2) algorithms in there). Pre-sorting the STATISTIC_KIND_MCV array as well, and replacing the linear searches with binary searches would alleviate that, which would be nice.
BTW: I just noticed some text_to_cstring calls, they came from elog(DEBUG1)s that I have in my code. But they couldn't have skewn the results much, could they?
Well, text_to_cstring was consuming 1.1% of the CPU time on its own, and presumably some of the AllocSetAlloc overhead is attributable to that as well. And perhaps some of the detoasting as well.
Speaking of which, a lot of time seems to be spent on detoasting. I'd like to understand that a better. Where is the detoasting coming from?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
