On Thu, 8 May 2003 g.hintermayer@inode.at wrote:
> > On Thu, 8 May 2003 09:20:31 +0200 (CEST), <g.hintermayer@inode.at>
> > wrote:
> >>So that's a factor of about 10 faster, only by changing the user, very
> >> strange.
> >
> > Very, very strange! Compare the outputs of SHOW ALL for both cases. If
> > there are any differences, please inform us.
> >
> >> -> Seq Scan on produkt (cost=0.00..2417.41 rows=2141
> >> width=40)
> > ^^^^ ^^^^
> >> (actual time=0.02..27.12 rows=2141
> >> loops=1)
> >
> > Unless I'm missing something, your produkt table has more pages than
> > tuples. VACUUM FULL should reduce its size to ca. 22 pages.
> >
> Could be, I'm running VACUUM only once a week.
>
> Well the whole problem seems to be because of different types of the
> joined columns.
> I rebuilt my database to have the same datatype on the joined columns
> (both character varying(10 now, before one text, one character
> varying(10)) and my query works as fast as in the other databases.
>
> Somebody shall correct me if I'm wrong, but that's what I found out:
>
> The optimizer *never* uses an index when doing NATURAL INNER JOIN when the
> joined rows have the same data type (at least I could'nt find a case where
> he does) regardless if ther's an index on the joined column in one or both
> tables or not.
I can get it to in at least some circumstances:
create table t1(a int unique);
create table t2(a int unique);
explain select * from t1 natural inner join t2;
Also, I didn't see an index on produkt.p_code which may or may not help in
general.
I'd have said if possible to try with enable_seqscan=off, but if there's
no index on the other I'm not sure the numbers would be meaningful.