"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> Ah, but you _can_ affect how the plans chosen, which in turn can affect
> the optimizer. Not as part of a running, production system, I grant you,
> but for debugging performance problems (and in particular, changes from
> one release to the next) it can be useful. What I'm talking about are
> the switches to the backend that tell pgsql not use particular kinds
> of joins/scans in planning a query
BTW, I have been thinking that it'd be a lot better if these flags could
be twiddled via SET/SHOW commands, instead of having to restart psql.
Nothing done about it yet, but it's an idea...
Also, you already can twiddle the basic cost parameters (cpu_page_weight
and cpu_index_page_weight) via SET variables whose names I forget at the
moment. There will be probably be at least one more such variable
before 7.0 comes out, to control cost of random page fetch vs. sequential.
regards, tom lane
