From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Dan Langille <dan(at)langille(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: index scan of whole table, can't see why |
Date: | 2005-01-20 15:26:37 |
Message-ID: | 20050120072205.G38768@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 20 Jan 2005, Dan Langille wrote:
> On 20 Jan 2005 at 6:14, Stephan Szabo wrote:
>
> > On Wed, 19 Jan 2005, Dan Langille wrote:
> >
> > > Hi folks,
> > >
> > > Running on 7.4.2, recently vacuum analysed the three tables in
> > > question.
> > >
> > > The query plan in question changes dramatically when a WHERE clause
> > > changes from ports.broken to ports.deprecated. I don't see why.
> > > Well, I do see why: a sequential scan of a 130,000 rows. The query
> > > goes from 13ms to 1100ms because the of this. The full plans are at
> > > http://rafb.net/paste/results/v8ccvQ54.html
> > >
> > > I have tried some tuning by:
> > >
> > > set effective_cache_size to 4000, was 1000
> > > set random_page_cost to 1, was 4
> > >
> > > The resulting plan changes, but no speed improvment, are at
> > > http://rafb.net/paste/results/rV8khJ18.html
> > >
> > > Any suggestions please?
> >
> > As a question, what does it do if enable_hashjoin is false? I'm wondering
> > if it'll pick a nested loop for that step for the element/ports join and
> > what it estimates the cost to be.
>
> With enable_hashjoin = false, no speed improvement. Execution plan
> at http://rafb.net/paste/results/qtSFVM72.html
Honestly I expected it to be slower (which it was), but I figured it's
worth seeing what alternate plans it'll generate (specifically to see how
it cost a nested loop on that join to compare to the fast plan).
Unfortunately, it generated a merge join, so I think it might require both
enable_hashjoin=false and enable_mergejoin=false to get it which is likely
to be even slower in practice but still may be useful to see.
From | Date | Subject | |
---|---|---|---|
Next Message | Hervé Piedvache | 2005-01-20 15:31:06 | Re: PostgreSQL clustering VS MySQL clustering |
Previous Message | Edgars Diebelis | 2005-01-20 15:24:37 | Re: PostgreSQL clustering VS MySQL clustering |