| From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Optimizer speed and GEQO (was: nested loops in joins) |
| Date: | 1999-02-06 14:21:40 |
| Message-ID: | 36BC4FF4.C7A63095@alumni.caltech.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Why are we maintaining this huge Path List for every RelOptInfo
> structure if we only need the cheapest? Why not store only the
> cheapest plan, instead of generating all unique plans, then using only
> the cheapest?
Just guessing here: does it use this same list to determine if a new
plan is a duplicate of a previously generated plan? Of course, maybe
that is not important, since any *cheaper* plan should be different from
any existing plan, and any plan of the same cost or higher could be
rejected.
Perhaps having the entire list of plans available makes it easier to
debug, especially when the stuff was in lisp (since in that environment
it is easy to traverse and manipulate these lists interactively)...
- Tom
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-02-06 17:06:54 | Re: [HACKERS] Optimizer speed and GEQO (was: nested loops in joins) |
| Previous Message | Bruce Momjian | 1999-02-06 12:49:03 | Re: [HACKERS] Optimizer speed and GEQO (was: nested loops in joins) |