On Mon, 12 Sep 2005 00:47:57 +0300, Ksenia Marasanova
<[EMAIL PROTECTED]> wrote:
> -> Seq Scan on user_ (cost=0.00..7430.63 rows=12763 width=245)
>(actual time=360.431..1120.012 rows=12763 loops=1)
If 12000 rows of the given size are stored in more than 7000 pages, then
there is a lot of free
* Ksenia Marasanova ([EMAIL PROTECTED]) wrote:
> test=# explain analyze select * from user_ left join church on
> user_.church_id = church.id;
[...]
> Total runtime: 2025.946 ms
> (6 rows)
>
> test=# set enable_seqscan='false';
> SET
> test=# explain analyze select * from user_ left join church o
2005/9/12, Stephen Frost <[EMAIL PROTECTED]>:
> * Ksenia Marasanova ([EMAIL PROTECTED]) wrote:
> > Any tips are greatly appreciated.
>
> EXPLAIN ANALYZE of the same queries would be much more useful.
Thanks, here it is:
test=# explain analyze select * from user_ left join church on
user_.church_
* Ksenia Marasanova ([EMAIL PROTECTED]) wrote:
> Any tips are greatly appreciated.
EXPLAIN ANALYZE of the same queries would be much more useful.
Thanks,
Stephen
signature.asc
Description: Digital signature
Hi list,
I don't have much experience with Postgres optimization, somehow I was
happily avoiding anything more difficult than simple select statement,
and it was working all right.
Now LEFT JOIN must be used, and I am not happy with the performance:
It takes about 5 seconds to run very simple LEF