From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Enrico <scotty(at)linuxtime(dot)it>, List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Index Scanning |
Date: | 2007-01-03 12:21:31 |
Message-ID: | 459B9FCB.1010405@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Don't forget to cc the list
Enrico wrote:
> On Wed, 03 Jan 2007 10:55:03 +0000
> Richard Huxton <dev(at)archonet(dot)com> wrote:
>
>> You're fetching all the rows from both tables - what would an index scan
>> gain you
>
> there is a join
Yes, there is a join. Between all the rows in tmp_righe_bolle_carico
(tr) and all the matches in bolle_carico_testata (tb). It looks like
there is one row in (tb) that matches each in (tr).
What do you expect two index scans over both tables would gain you?
You seem to be saying that you think:
fetching 22420 index entries on tr + fetching 22420 rows in tr
+ fetching 22420 index entries on tb + fetching 22420 rows in tb
+ merge-join
would be faster than the hash-join you've got. I think it's unlikely
that's the case.
If you issue "set enable_seqscan = off" before the query that should
force it to use the indexes first. What does that plan show you?
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2007-01-03 14:05:24 | "no unpinned buffers available" ? why? (hstore and plperl involved) |
Previous Message | Ron Johnson | 2007-01-03 12:10:32 | Re: queueing via database table? |