| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Dimitri Fontaine" <dim(at)hi-media(dot)com> |
| Subject: | Re: *_collapse_limit, geqo_threshold |
| Date: | 2009-07-11 18:27:27 |
| Message-ID: | 200907112027.27404.andres@anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Saturday 11 July 2009 18:23:59 Tom Lane wrote:
> On reflection I think the best user API is probably a "geqo_seed" GUC in
> the range 0 to 1, and have GEQO always reset its seed to that value at
> start of a planning cycle. This ensures plan stability, and if you need
> to experiment with alternative plans you can change to different seed
> values. The "no reset" behavior doesn't seem to have much real-world
> usefulness, because even if you chance to get a good plan, you have no
> way to reproduce it...
I just realized doing it in a naive way (in geqo()) causes the state to be
reset multiple times during one query- at every invocation of
make_rel_from_joinlist.
Does anybody see a problem with that?
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-07-11 18:33:14 | Re: *_collapse_limit, geqo_threshold |
| Previous Message | Kenneth Marshall | 2009-07-11 17:28:30 | Re: *_collapse_limit, geqo_threshold |