On Sat, Jun 14, 2008 at 02:35:38PM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I created a test case that has close to the same estimated and
actual row counts and has the same plan if I disable enable_nestloop:
There's something weird about this --- why does the second
Michael Fuhr [EMAIL PROTECTED] schrieb:
On Sat, Jun 14, 2008 at 04:59:44PM +0200, Andreas Kretschmer wrote:
Julius Tuskenis [EMAIL PROTECTED] schrieb:
I have a question concerning performance. One of my queries take a long
to execute. I tried to do explain analyse and I see that the
Hello, Tom.
So I think the OP's
problem is purely a statistical one, or maybe he's in a situation where
he should reduce random_page_cost.)
What could be done solving that statistical problem? :) Current value
for random_page_cost is 4. What value would you suggest?
Julius Tuskenis
--
Hi Michael.
Thank you for your answer. I've checked - enable_nestloop is true. I did
ANALYZE, but that didn't help. The sequential scan is still used Any
more ideas why?
Julius Tuskenis
Michael Fuhr rašė:
On Sat, Jun 14, 2008 at 04:59:44PM +0200, Andreas Kretschmer wrote:
Julius
Hello.
I have a question concerning performance. One of my queries take a long
to execute. I tried to do explain analyse and I see that the
sequential scan is being used, although I have indexes set on columns
that are used in joins. The question is - WHY, and how to change that
behavior???
Julius Tuskenis [EMAIL PROTECTED] schrieb:
Hello.
I have a question concerning performance. One of my queries take a long
to execute. I tried to do explain analyse and I see that the
sequential scan is being used, although I have indexes set on columns
that are used in joins. The
On Sat, Jun 14, 2008 at 04:59:44PM +0200, Andreas Kretschmer wrote:
Julius Tuskenis [EMAIL PROTECTED] schrieb:
I have a question concerning performance. One of my queries take a long
to execute. I tried to do explain analyse and I see that the
sequential scan is being used, although I
Michael Fuhr [EMAIL PROTECTED] writes:
I created a test case that has close to the same estimated and
actual row counts and has the same plan if I disable enable_nestloop:
There's something weird about this --- why does the second plan seqscan
b_saskaita, instead of using the bitmap scan that
