| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
| Cc: | Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #5652: Optimizer does wrong thing with partitioned tables |
| Date: | 2010-09-17 01:29:19 |
| Message-ID: | AANLkTi=8HaHLehroY+ZzcJY8M5KG5xKxndKH+pZeud9T@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Sep 10, 2010 at 9:31 AM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> 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 index for a partitioned
> table nor an optimizer artifact to know aggregate information before scanning
> all of the partitions. Maybe when we have a better support for table
> partitioning such optimizer artifact would be implemented but don't hold your
> breath.
I wonder if Merge Append could be made to help with this case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-09-17 01:30:36 | Re: BUG #5644: Selecting ROW() in variable with 9.0 not compatible with 8.4 |
| Previous Message | Robert Haas | 2010-09-17 01:26:52 | Re: BUG #5644: Selecting ROW() in variable with 9.0 not compatible with 8.4 |