From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Franck Routier <franck(dot)routier(at)axege(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: What happens between end of explain analyze and end of query execution ? |
Date: | 2013-04-08 16:46:26 |
Message-ID: | 16275.1365439586@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Sat, Apr 6, 2013 at 9:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah, eqjoinsel() is O(N^2) in the lengths of the MCV lists, in the
>> worst case where there's little overlap in the list memberships.
> I guess this pre-emptively answers a question I was intending to ask on
> performance: Whether anyone increased default_statistics_target and came
> to regret it. I had seen several problems fixed by increasing
> default_statistics_target, but this is the first one I recall caused by
> increasing it.
I recall having heard some similar complaints before, but not often.
> Do you think fixing the O(N^2) behavior would be a good to-do item?
If you can think of a way to do it that doesn't create new assumptions
that eqjoinsel ought not make (say, that the datatype is sortable).
I guess one possibility is to have a different join selectivity function
for those types that *are* sortable, which would fix the issue for most
commonly used types.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Davidson | 2013-04-08 17:02:59 | Re: INDEX Performance Issue |
Previous Message | Jeff Janes | 2013-04-08 16:39:01 | Re: What happens between end of explain analyze and end of query execution ? |