Re: gsoc, oprrest function for text search take 2 - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: gsoc, oprrest function for text search take 2
Date
Msg-id 48A3FDF2.8050606@enterprisedb.com
Whole thread Raw
In response to Re: gsoc, oprrest function for text search take 2  (Jan Urbański <j.urbanski@students.mimuw.edu.pl>)
Responses Re: gsoc, oprrest function for text search take 2  (Jan Urbański <j.urbanski@students.mimuw.edu.pl>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: gsoc, oprrest function for text search take 2
Next
From: Simon Riggs
Date:
Subject: Re: [PERFORM] autovacuum: use case for indenpedent TOAST table autovac settings