Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ivan Sergio Borgonovo <mail@webthatworks.it> writes:
> > Well I reached 3Gb of work_mem and still I got:
>
> > "Seq Scan on catalog_categoryitem (cost=31747.84..4019284477.13
> > rows=475532 width=6)"
> > " Filter: (NOT (subplan))"
> > " SubPlan"
> > " -> Materialize (cost=31747.84..38509.51 rows=676167
> > width=8)" " -> Seq Scan on catalog_items
> > (cost=0.00..31071.67 rows=676167 width=8)"
>
> Huh. The only way I can see for that to happen is if the datatypes
> involved aren't hashable. What's the datatypes of the two columns
> being compared, anyway?
I changed both columns to bigint.
I added 2 indexes on the ItemID column of both tables and increased
work_mem to 3Gb [sic].
The query got executed in ~1300ms... but explain gave the same
output as the one above.
The problem is solved... but curious mind want to know.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
No comments:
Post a Comment