Re: [PERFORM] Spatial join insists on sequential scan of larger

2004-04-03 Thread Clive Page
rows=177023872 width=48) (actual time=22.064..617462.486 rows=177757299 loops=1) -> Index Scan using xmmbox on xmm1 x (cost=0.00..1107.28 rows=280 width=48) (actual time=0.036..0.036 rows=0 loops=177757299) Index Cond: (x.errbox && "outer".errbox) Total runtime

Re: [PERFORM] Spatial join insists on sequential scan of larger

2004-04-02 Thread Clive Page
his afternoon. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

[PERFORM] Spatial join insists on sequential scan of larger table

2004-04-02 Thread Clive Page
an outer join should be faster than an inner one, or to put it another way, after dropping an index there is more than an order of magnitude speed increase. I'm using Postgres 7.4.1 on Red Hat Linux. Has anyone had similar problems with spatial joins? -- Cl

[PERFORM] Inefficient SELECT with OFFSET and LIMIT

2004-01-06 Thread Clive Page
ld be implemented in some more efficient way. -- Clive Page, Dept of Physics & Astronomy, University of Leicester, U.K. ---(end of broadcast)--- TIP 8: explain analyze is your friend