pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Craig Ringer <ringerc@ringerc.id.au>
To: Robert Klemme <shortcutter@googlemail.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Any tool/script available which can be used to measure scalability of an application's database.
Date: Sat, 14 Jul 2012 23:10:52 +0800
Message-ID: <50018BFC.1080701@ringerc.id.au> (raw)
In-Reply-To: <CAM9pMnPTF-MQCdM7BE45gWS_zMTGX1jNev0EGNXgSjCdMLJizw@mail.gmail.com>
References: <OF43A6984C.A368D80E-ON65257A37.00211A41-65257A37.002DEE2E@tcs.com>
	<CAM9pMnMcsU0qWb_a2xPHdJ5oobscptE5votqY2T95GnRw7c=pA@mail.gmail.com>
	<CANVt3iY4ipHJG3+j=c6iO7GDRBT4m-hKAMD=mkf9P8k6q8S_Uw@mail.gmail.com>
	<50013279.4090407@ringerc.id.au>
	<CANVt3iYn_VUvxPDs67smQbCUsRuGejwHeHWm_itgGbVCxeUgKA@mail.gmail.com>
	<CAM9pMnPTF-MQCdM7BE45gWS_zMTGX1jNev0EGNXgSjCdMLJizw@mail.gmail.com>

On 07/14/2012 08:17 PM, Robert Klemme wrote:
> On Sat, Jul 14, 2012 at 11:50 AM, B Sreejith <bsreejithin@gmail.com> wrote:
>> Dear All,
>> Thanks alot for all the invaluable comments.
> Additionally to Craig's excellent advice to measurements there's
> something else you can do: with the knowledge of the queries your
> application fires against the database you can evaluate your schema
> and index definitions.  While there is no guarantee that your
> application will scale well if all indexes are present
Don't forget that sometimes it's better to DROP an index that isn't used 
much, or that only helps occasional queries that aren't time-sensitive. 
Every index has a cost to maintain - it slows down your inserts and 
updates and it competes for disk cache with things that might be more 
beneficial.
> b) do not have indexes nor no indexes which
> support the queries your application does against these tables which
> will result in full table scans.
A full table scan is not inherently a bad thing, even for a huge table. 
Sometimes you just need to examine every row, and the fastest way to do 
that is without a doubt a full table scan.

Remember, a full table scan won't tend to push everything out of 
shared_buffers, so it can also avoid competition for cache.

(If anyone ever wants concurrent scans badly enough to implement them, 
full table scans with effective_io_concurrency > 1 will become a *lot* 
faster for some types of query).

--
Craig Ringer



view thread (12+ messages)

Message-ID: <50018BFC.1080701@ringerc.id.au>
Permalink:  ../50018BFC.1080701@ringerc.id.au/
Also on:    postgresql.org/message-id/50018BFC.1080701@ringerc.id.au

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: ringerc@ringerc.id.au, shortcutter@googlemail.com
  Subject: Re: Any tool/script available which can be used to measure scalability of an application's database.
  In-Reply-To: <50018BFC.1080701@ringerc.id.au>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox