Skip site navigation (1) Skip section navigation (2)

Re: Hash or merge join instead of inner loop

From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Hash or merge join instead of inner loop
Date: 2003-06-10 08:56:17
Message-ID: 3EE5EA89.19260.8C8B669@localhost (view raw or flat)
Thread:
Lists: pgsql-performance
On 10 Jun 2003 at 2:15, Tom Lane wrote:

> There's been some discussion about that before; you could check the
> archives (now that they're up again ;-)).  I believe that the planner
> overestimates the cost of a nestloop with inner indexscan, because it
> costs the indexscans as though each one is an independent ab-initio
> index search.  In reality, most of the upper btree levels will no doubt
> stay in memory during such a query, and so this estimate charges many
> more reads than really occur.  Fixing this is on the todo list, but no
> one's got to it yet.  (It's not clear to me how to put the consideration
> into the planner's cost algorithms in a clean way.)

Just being naïve here, but if planner and executor account for shared 
buffers+effective OS cache, even a boolean choice could be a start.

Say a query needs 100MB of data according to estimates so if shared 
buffers+effective OS cache covers that, we can lower the cost.

May be we should have two config. parameters for tuple cost? Disk read tuple 
cost and memory read tuple cost. Later being 1/10th of former?

Bye
 Shridhar

--
All new:	Parts not interchangeable with previous model.


In response to

pgsql-performance by date

Next:From: Josh BerkusDate: 2003-06-10 15:46:21
Subject: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning
Previous:From: Tom LaneDate: 2003-06-10 06:15:11
Subject: Re: Hash or merge join instead of inner loop

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group