I also suppose, that the new implementation is more consistent, but probably
a hint in the compatibility list should be done, so that after migration
Stored Procedures that are using the buggy implementation on the 8.4 should
be rewritten.
And the rewriting should be done either only after the mig
Tom and Chris - thank you for your answers. There are several reasons for
not including /usr/local/include. Some of those reasons are that I do not
want to be adding files to /usr/include - when it concerns dependencies I
have had to build before getting started. But that is my choice. No further
c
The following bug has been logged online:
Bug reference: 5652
Logged by: Mladen Gogala
Email address: mladen.gog...@vmsinfo.com
PostgreSQL version: 8.4.4
Operating system: Red Hat Linux 5.5, 64b
Description:Optimizer does wrong thing with partitioned tables
Details:
Mladen Gogala escreveu:
> Optimizer chooses to scan each partitioned table sequentially, instead of
> using the available index:
>
This is not a bug. How would the optimizer know that the maximum value is in
that specific partition? There is neither a global index for a partitioned
table nor an op
Euler Taveira de Oliveira wrote:
Mladen Gogala escreveu:
Optimizer chooses to scan each partitioned table sequentially, instead of
using the available index:
This is not a bug. How would the optimizer know that the maximum value is in
that specific partition? There is neither a global
Just adding my voice to the "fix it" camp. Is there any reason the
table scans in this sort of thing cannot be independently planned?
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Fri, 2010-09-10 at 10:37 -0400, Mladen Gogala wrote:
> Euler, optimizer is selecting a wrong path, which is a bug by
> definition.
I agree that the optimizer should be improved here, but it's not really
a "bug". I think what you are requesting is considered more of a feature
to make the optimi
On Fri, 2010-09-10 at 08:10 -0700, Chris Travers wrote:
> Just adding my voice to the "fix it" camp. Is there any reason the
> table scans in this sort of thing cannot be independently planned?
I don't think it's about independent planning. For instance, AVG clearly
can't be planned this way, the
Jeff Davis wrote:
On Fri, 2010-09-10 at 08:10 -0700, Chris Travers wrote:
Just adding my voice to the "fix it" camp. Is there any reason the
table scans in this sort of thing cannot be independently planned?
I don't think it's about independent planning. For instance, AVG clearly
can'
On Fri, 2010-09-10 at 16:53 -0400, Mladen Gogala wrote:
> Jeff, that's the problem. Functions like "MAX" are rather ordinary and
> frequently used.
I agree that it could be improved. The best way to move such improvement
forward is to advance the discussion on -hackers. Start with this thread
h
On Fri, Sep 10, 2010 at 1:53 PM, Mladen Gogala wrote:
> Jeff, that's the problem. Functions like "MAX" are rather ordinary and
> frequently used. Using sequential scan to read all partitions is the wrong
> thing to do. I agree that AVG() cannot be computed using index but MAX() and
> MIN() can. I
Jeff Davis wrote:
On Fri, 2010-09-10 at 16:53 -0400, Mladen Gogala wrote:
Jeff, that's the problem. Functions like "MAX" are rather ordinary and
frequently used.
I agree that it could be improved. The best way to move such improvement
forward is to advance the discussion on -hackers.
12 matches
Mail list logo
