Tom Lane wrote:
>
> Do a VACUUM ANALYZE, for starters. These results look like the planner
> is working with the initial default estimates for a never-vacuumed table.
>
>
> Indexes might be a good idea too.
> http://www.postgresql.org/devel-corner/docs/postgres/indices.html
> has a good intro to
Renaud Tthonnart <[EMAIL PROTECTED]> writes:
> Nested Loop (cost=0.00..56.67 rows=3 width=20)
> -> Seq Scan on observation o (cost=0.00..30.00 rows=1 width=4)
> -> Seq Scan on exposure_epic e (cost=0.00..22.50 rows=333 width=16)
Do a VACUUM ANALYZE, for starters. These results look like
Here they are :
EXPLAIN
(SELECT e.name
FROM Observation o, Exposure_EPIC e
WHERE o.numObs = e.obs
AND e.instrPN IS NOT NULL
AND o.RA BETWEEN 3 AND 5);
NOTICE: QUERY PLAN:
Hash Join (cost=25.02..60.98 rows=33 width=20)
-> Seq Scan on exposure_epic e (cost=0.00..22.50 rows=333 width=16
On Thu, Feb 22, 2001 at 05:10:51PM +0100, Renaud Tthonnart wrote:
> This qwery takes about 2 seconds :
[..]
Can you send us the output of EXPLAIN for each of these queries?
Also, how large are the tables you're working with? What
indexes have been created?
Cheers,
Neil
--
Neil Conway <[EMAIL
This qwery takes about 2 seconds :
SELECT e.name
FROM Observation o, Exposure_EPIC e
WHERE o.numObs = e.obs
AND e.instrPN IS NOT NULL
AND o.RA BETWEEN 3 AND 5;
This one about 5 seconds :
SELECT e.name
FROM Observation o, Exposure_EPIC e
WHERE o.numObs = e.obs
AND e.instrPN IS NOT NULL