Dnia 2003-11-28 22:57, Użytkownik Tom Lane napisał:
Restructure planning of nestloop inner indexscans so that the set
of usable joinclauses is determined accurately for each join.
Formerly, the code only considered joinclauses that used all of the
rels from the outer side of the join; thus for
Tomasz Myrta <[EMAIL PROTECTED]> writes:
> It's much better now (10x faster), but I've just found this plan still
> isn't as I want to have. I wish I could have index usage on both fields,
FWIW, I see this plan in 7.4 using your original test case:
Nested Loop (cost=22.51..71.79 rows=1 width=
Dnia 2003-11-28 20:52, Użytkownik Tom Lane napisał:
Tomasz Myrta <[EMAIL PROTECTED]> writes:
If I add "and k.id_trasy=lt.id_trasy" into where clause (duplicate), the
query works fine.
Define "works fine", please (again, EXPLAIN ANALYZE would be a nice
concrete description).
Sorry, I thought th
Tomasz Myrta <[EMAIL PROTECTED]> writes:
> If I add "and k.id_trasy=lt.id_trasy" into where clause (duplicate), the
> query works fine.
Define "works fine", please (again, EXPLAIN ANALYZE would be a nice
concrete description).
regards, tom lane
--
Dnia 2003-11-28 20:18, Użytkownik Tom Lane napisał:
Hard to say much when you didn't actually show us the output of EXPLAIN
ANALYZE.
OK, Here you are:
explain analyze select *
from plany pl
join linia_trasy lt using (id_linii)
join kursy k on (k.id_trasy=lt.id_trasy and
k.event_date=pl.begind
Tomasz Myrta <[EMAIL PROTECTED]> writes:
> Postgres doesn't use join on these both fields and doesn't use index
> scan properly.
Hard to say much when you didn't actually show us the output of EXPLAIN
ANALYZE.
regards, tom lane
---(end of broadcas
Hi
SELECT version();
PostgreSQL 7.3.4 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc
(GCC) 3.3.2 20031005 (Debian prerelease)
Let's say I have 3 tables:
groups (
groupid integer primary key,
namevarchar,
begindate date
);
offsets (
offset_id integer,
groupid
