Re: eliminating records not in (select id ... so SLOW?

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: eliminating records not in (select id ... so SLOW?
Date: 2008-08-01 15:04:15
Message-ID: 20080801170415.1c1bd2d0@dawn.webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 01 Aug 2008 10:33:59 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ivan Sergio Borgonovo <mail(at)webthatworks(dot)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?

That S in CS should mean sober!

thanks to svn I'd say you're right... one column was int the other
bigint.
Among other things I was just fixing that kind of mistakes.

If that could be the reason I'll report if things got better once I
finish to normalise the DB.

BTW does pg 8.3 save you from such kind of mistake being stricter
with auto cast?

Tom sorry for sending this just to your personal email.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2008-08-01 15:08:32 Re: eliminating records not in (select id ... so SLOW?
Previous Message Tom Lane 2008-08-01 14:33:59 Re: eliminating records not in (select id ... so SLOW?