| From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
| Cc: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, jd(at)commandprompt(dot)com, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Greg Smith" <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Simple postgresql.conf wizard |
| Date: | 2008-12-06 03:46:10 |
| Message-ID: | 603c8f070812051946u2029bab0l632284eec80b9d76@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Looking at eqjoinsel I think it could be improved algorithmically if we keep
> the mcv list in sorted order, even if it's just binary sorted order. But I'm
> not sure what else uses those values and whether the current ordering is
> significant. I'm also not sure it's the only O(n^2) algorithm there and
> there's no algorithmic gain unless they're all knocked down.
The current code seems to be trying to handle pathological cases where:
(1) the operator for which it is invoked doesn't really represent
equality and/or
(2) the type has an equality operator but no comparison operator.
Those are important cases, but maybe we could create an alternative
version for the fairly common situation where neither holds?
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2008-12-06 04:16:24 | Re: default statistics target testing (was: Simple postgresql.conf wizard) |
| Previous Message | Robert Haas | 2008-12-06 03:08:13 | Re: default statistics target testing (was: Simple postgresql.conf wizard) |