| From: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> |
|---|---|
| To: | Alex Solovey <a(dot)solovey(at)gmail(dot)com> |
| Cc: | "Rodrigo E(dot) De León Plicet" <rdeleonp(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Problem with planner choosing nested loop |
| Date: | 2008-04-03 06:34:29 |
| Message-ID: | 74D87096-645C-499B-A8FD-28B15F959141@solfertje.student.utwente.nl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Apr 2, 2008, at 9:02 PM, Alex Solovey wrote:
> The reduced database example has the same problem in EXPLAIN
> ANALYZE as production one, here:
>
> Seq Scan on bar (cost=0.00..393.07 rows=1 width=4) (actual
> time=0.098..3.561 rows=24 loops=1)
Hang on... You prefer sequential scans because indexes make your
database too slow, but you don't want a sequential scan now? What
kind of solution do you expect then? An oracle maybe?
You will need an index if this query is too slow for you, or you will
have to live with the slowness of this query. Pick one ;)
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47f47a7a927661963919006!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2008-04-03 07:03:38 | Re: Problem with planner choosing nested loop |
| Previous Message | Tom Lane | 2008-04-03 05:00:41 | Re: Serial Data Type |