From: | Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk> |
---|---|
To: | Fabian Kreitner <fabian(dot)kreitner(at)ainea-ag(dot)de> |
Cc: | "pgsql-performance (at) postgresql (dot) org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: index / sequential scan problem |
Date: | 2003-07-17 14:38:25 |
Message-ID: | 20030717153825.C27991@bacon |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 17/07/2003 13:50 Fabian Kreitner wrote:
> [snip]
> Im afraid, no.
> Database has been stopped / started right before this.
> [snip]
1) enable_seqscan = true
> Seq Scan on notiz_objekt a (cost=0.00..56125.80 rows=15561 width=12)
> (actual time=0.28..2298.71 rows=31122 loops=1)
> [snip]
2) enable_seqscan = false
> Seq Scan on notiz_objekt a (cost=100000000.00..100111719.36 rows=15561
> width=12) (actual time=0.25..535.75 rows=31122 loops=1)
I've just noticed this. Something is not right here. Look at the crazy
cost estimation for the second query. It looks to me like
enable_indexscan, enable_tidscan, enable_sort, enable_nestloop,
enable_mergejoin or enable_hashjoin have been set to false. Looking at the
source, thats the only way I can see that such large numbers can be
produced.
HTH
--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Moran | 2003-07-17 14:45:35 | Relation of indices to ANALYZE |
Previous Message | Jord Tanner | 2003-07-17 14:10:35 | Re: index / sequential scan problem |