From: | Ben <bench(at)silentmedia(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: very slow left join |
Date: | 2008-05-16 18:21:04 |
Message-ID: | Pine.LNX.4.64.0805161113520.3347@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 16 May 2008, Scott Marlowe wrote:
> Just for giggles, try running the query like so:
>
> set enable_nestloop = off;
> explain analyze ...
>
> and see what happens. I'm guessing that the nested loops are bad choices here.
You guess correctly, sir! Doing so shaves 3 orders of magnitude off the
runtime. That's nice. :) But that brings up the question of why postgres
thinks nested loops are the way to go? It would be handy if I could make
it guess correctly to begin with and didn't have to turn nested loops off
each time I run this.
>> Table "public.event"
>> Column | Type | Modifiers
>> ----------------+-----------------------------+------------------------
>> clientkey | character(30) | not null
>> premiseskey | character(30) | not null
>> eventkey | character(30) | not null
>> severitykey | character(30) |
>
> Do these really need to be character and not varchar? varchar / text
> are better optimized in pgsql, and character often need to be cast
> anyway, so you might as well start with varchar. Unless you REALLY
> need padding in your db, avoid char(x).
Unfortuantely, the people who created this database made all keys 30
character strings, and we're not near a place in our release cycle where
we can fix that.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-05-16 18:23:55 | Re: I/O on select count(*) |
Previous Message | Scott Marlowe | 2008-05-16 18:09:46 | Re: very slow left join |