From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 7.4 compatibility question |
Date: | 2003-10-24 04:06:35 |
Message-ID: | 87brs71dpw.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Michael Brusser wrote:
>
> > Optimizer improvements
> > => this tells me nothing. I suppose this could be a minor internal code
> > tweak, which does not affect me. On the other hand this could be a major
> > breakthrough, so now I can run some stupid query which would take
> > a week to complete in the previous release. How do I know?
>
> Yes, this is always very hard to explain. The optimizer itself is
> complex, and uses complex terms like merge join and key pruning. It is
> hard to explain what queries will be affected, though the basic issue is
> that the optimizer will choose a better plan more frequently.
One thing that might be worth mentioning is that "WHERE foo IN (subquery)"
type queries are much improved. That's a one of the more common complaints
about 7.3 and previous and it's one that fairly easy to recognize.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-10-24 04:09:17 | Re: 7.4 compatibility question |
Previous Message | Peter Eisentraut | 2003-10-23 18:53:26 | Re: Why do we have "gcc default optimizations" docs? |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-10-24 04:07:25 | Re: Broken Constraint Checking in Functions |
Previous Message | Satoshi Nagayasu | 2003-10-24 03:57:29 | Re: 2-phase commit |