tom lane wrote:
Why does it think that only 159 of the 132245 rows in outages will have
join partners in ipinterface? The actual results look like they all do.
It might be worth looking at the pg_stats rows for the join columns to
see if there's something odd about the statistics.
Here are
Dave E Martin <[EMAIL PROTECTED]> writes:
> tom lane wrote:
>>> Why does it think that only 159 of the 132245 rows in outages will have
>>> join partners in ipinterface? The actual results look like they all do.
>>> It might be worth looking at the pg_stats rows for the join columns to
>>> see if
tom lane wrote:
> Why does it think that only 159 of the 132245 rows in outages will have
> join partners in ipinterface? The actual results look like they all do.
> It might be worth looking at the pg_stats rows for the join columns to
> see if there's something odd about the statistics.
>
He
Dave E Martin <[EMAIL PROTECTED]> writes:
> I have noticed that if I set enable_sort=false in the .conf file, my
> queries are running faster.
You mean one specific example is running faster. If you do that you'll
probably slow down other queries.
It looks like the main estimation error is here
Dave E Martin wrote:
(8.0.1 on debian/linux 2.6.11 kernel)
I have noticed that if I set enable_sort=false in the .conf file, my
queries are running faster. I had a query which if I did a limit 20, ran
in 6 milliseconds, but if I changed it to limit 21, it took around 19
seconds (or 19000 mill
(8.0.1 on debian/linux 2.6.11 kernel)
I have noticed that if I set enable_sort=false in the .conf file, my
queries are running faster. I had a query which if I did a limit 20, ran
in 6 milliseconds, but if I changed it to limit 21, it took around 19
seconds (or 19000 milliseconds). It also too
