Re: 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