From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndQuadrant.com>
cc: Jeff Janes <jeff.janes@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PERFORM] Slow query: bitmap scan troubles
In-reply-to: 
 <CA+U5nMKbOGVfQXfJi5_vOUPEatF_V_+e_HX4P5R=tb9JSo2ceA@mail.gmail.com>
References: <092a01cdd230$ff6143c0$fe23cb40$@foo.me.uk>
	<CAGTBQpaKOfZs+qy+S7CCPcTg7PYOrwgcQAXgWV88cQTn-BFstg@mail.gmail.com>
	<CAMkU=1wEc1cCeUdR1oZ3Q2fe2pGj6tvrwRcY2obbfEk8LcNypQ@mail.gmail.com>
	<097601cdd249$ae338530$0a9a8f90$@foo.me.uk>
	<CAMkU=1wmxKifgUufbSffQ+VH3kFNczK65MxXetwVFJZd3zvkeA@mail.gmail.com>
	<CAMkU=1w40aQt0twukCsvL2hPHUPujLqJBe8v90phuqBJ5wgw1Q@mail.gmail.com>
	<9022.1354730710@sss.pgh.pa.us>
	<CAMkU=1ykyMgXccv2dAWKOXdDx5U0Qpc28aW6k659hvE7VZEMXQ@mail.gmail.com>
	<28944.1357424296@sss.pgh.pa.us>
	<CA+U5nMLJBrnU+B6md5VR1GHGz6Ji5MEZd6QE+favQYLjv9H8JA@mail.gmail.com>
	<18164.1357498720@sss.pgh.pa.us>
	<CA+U5nMLjf2-kTa4-AR-0XLKKwbc+=_fb4237i_UAWYzowW+-1Q@mail.gmail.com>
	<8539.1357513385@sss.pgh.pa.us> <12791.1357580151@sss.pgh.pa.us>
	<CA+U5nMKbOGVfQXfJi5_vOUPEatF_V_+e_HX4P5R=tb9JSo2ceA@mail.gmail.com>
Comments: In-reply-to Simon Riggs <simon@2ndQuadrant.com>
	message dated "Mon, 07 Jan 2013 18:03:37 +0000"
Date: Mon, 07 Jan 2013 13:27:38 -0500
Message-ID: <13842.1357583258@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Simon Riggs <simon@2ndQuadrant.com> writes:
> On 7 January 2013 17:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That gives a formula of
>>	cpu_operator_cost * log2(N) + cpu_operator_cost * 50 * (H+2)

> Again, this depends on N and H, so thats good.

> I think my retinas detached while reading your explanation, but I'm a
> long way from coming up with a better or more principled one.

> If we can describe this as a heuristic that appears to fit the
> observed costs, we may keep the door open for something better a
> little later.

I'm fairly happy with the general shape of this formula: it has a
principled explanation and the resulting numbers appear to be sane.
The specific cost multipliers obviously are open to improvement based
on future evidence.  (In particular, I intend to code it in a way that
doesn't tie the "startup overhead" and "cost per page" numbers to be
equal, even though I'm setting them equal for the moment for lack of a
better idea.)

One issue that needs some thought is that the argument for this formula
is based entirely on thinking about b-trees.  I think it's probably
reasonable to apply it to gist, gin, and sp-gist as well, assuming we
can get some estimate of tree height for those, but it's obviously
hogwash for hash indexes.  We could possibly just take H=0 for hash,
and still apply the log2(N) part ... not so much because that is right
as because it's likely too small to matter.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers