Re: [HACKERS] gsoc, oprrest function for text search take 2

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