DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:cc:subject:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	b=LoWrHYKTfdKVnOp1g8dVlnrJOximfxamITIkYXPRbR+R1K0vpfyMrGp6EnQZbPk+Uc
	66/T205QWwGhgDzVfT/wAhzOaRYX9MB1vsEX6FqLH60vMw4a9iqd9w91DUoisxcL1Ws8
	WGfcYdMuO+aKTvsqWQwadKF0XDAfJtAVyZG9w=
Message-ID: <4cb25a0e.2a978e0a.7797.33d6@mx.google.com>
Date: Sun, 10 Oct 2010 18:27:53 -0600
From: Joshua Tolley <eggyknap@gmail.com>
To: Craig Ringer <craig@postnewspapers.com.au>
Cc: mladen.gogala@vmsinfo.com, Neil Whelchel <neil.whelchel@gmail.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Slow count(*) again...
References: <201010091626.18636.neil.whelchel@gmail.com>
	<4CB11CC7.8070300@vmsinfo.com>
	<4CB167CA.9070109@postnewspapers.com.au>
	<4CB1F46E.80205@vmsinfo.com>
	<4CB2410C.6010603@postnewspapers.com.au>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+Z7/5fzWRHDJ0o7Q"
Content-Disposition: inline
In-Reply-To: <4CB2410C.6010603@postnewspapers.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)


--+Z7/5fzWRHDJ0o7Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 11, 2010 at 06:41:16AM +0800, Craig Ringer wrote:
> On 10/11/2010 01:14 AM, Mladen Gogala wrote:
>
>> I can provide measurements, but from Oracle RDBMS. Postgres doesn't
>> allow tuning of that aspect, so no measurement can be done. Would the
>> numbers from Oracle RDBMS be acceptable?
>
> Well, they'd tell me a lot about Oracle's performance as I/O chunk size =
=20
> scales, but almost nothing about the cost of small I/O operations vs =20
> larger ones in general.
>
> Typically dedicated test programs that simulate the database read =20
> patterns would be used for this sort of thing. I'd be surprised if =20
> nobody on -hackers has already done suitable testing; I was mostly =20
> asking because I was interested in how you were backing your assertions.

One thing a test program would have to take into account is multiple
concurrent users. What speeds up the single user case may well hurt the
multi user case, and the behaviors that hurt single user cases may have been
put in place on purpose to allow decent multi-user performance. Of course, =
all
of that is "might" and "maybe", and I can't prove any assertions about block
size either. But the fact of multiple users needs to be kept in mind.

It was asserted that reading bigger chunks would help performance; a respon=
se
suggested that, at least in Linux, setting readahead on a device would
essentially do the same thing. Or that's what I got from the thread, anyway.
I'm interested to know how similar performance might be between the large
block size case and the large readahead case. Comments, anyone?

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

--+Z7/5fzWRHDJ0o7Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkyyWgkACgkQRiRfCGf1UMOx3wCdHaEfwtKu2FHHTJnM0w35cim3
tgEAnRq5Ee/E+WtN8Ton7b/ZOiHzOgKE
=/7qb
-----END PGP SIGNATURE-----

--+Z7/5fzWRHDJ0o7Q--