On Fri, Sep 10, 2010 at 9:31 AM, 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 p
On Fri, Sep 10, 2010 at 11:34:16PM -0400, Mladen Gogala wrote:
> 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 mov
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.
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
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
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 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
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
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
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
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
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:
12 matches
Mail list logo
