| 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: | Whole Thread | Raw Message | 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 ? |