I asked this on general, but didn't receive any responses. Is it possible
via SQL to identify the time of the last stat reset (or pg_stat_reset()
call)? This is what I'm lacking to be able to measure query activity
volume over time via SQL, i.e., maybe a function similar to the fictitious
pg
e for
technical archives, IMO. What a loss.
Question: What's the next best site/tool for searching technical usenet
archives??
Regards,
Ed Loehr
bug in the core planner, since
> GEQO has essentially no influence over whether the produced plan is
> correct or not. GEQO merely forces specific choices of join order.
> All else is in the core planner.
You can remove the randomness by setting the Seed configuration value, if
the docs a
hat I can recall.
At risk of being off-topic here, is there a reason why GEQO is off by
default in the ODBC driver (postdrv.exe)? I vaguely recall something
about this from a year ago, but can't find it.
Regards,
Ed Loehr
Tom Lane wrote:
>
> Ed Loehr <[EMAIL PROTECTED]> writes:
> > What is the status of the genetic algorithm query optimizer? Is this
> > supposed to work well on many-table joins, or has it fallen out of favor
> > or in disrepair?
>
> It's supposed to
Thomas Lockhart wrote:
>
> > What is the status of the genetic algorithm query optimizer? Is this
> > supposed to work well on many-table joins, or has it fallen out of favor
> > or in disrepair? [I'm needing to optimize some large, many-table-join
> > queries and wondering time spent configuri
: fk_employee_currency referential integrity violation - key '27'
referenced from employee not found in currency
Regards,
Ed Loehr