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

Re: Any tool/script available which can be used to measure scalability of an application's database.

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Robert Klemme <shortcutter(at)googlemail(dot)com>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Any tool/script available which can be used to measure scalability of an application's database.
Date: 2012-07-14 15:10:52
Message-ID: 50018BFC.1080701@ringerc.id.au (view raw or flat)
Thread:
Lists: pgsql-performance
On 07/14/2012 08:17 PM, Robert Klemme wrote:
> On Sat, Jul 14, 2012 at 11:50 AM, B Sreejith <bsreejithin(at)gmail(dot)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

In response to

pgsql-performance by date

Next:From: Jeff JanesDate: 2012-07-15 00:10:18
Subject: Re: [PERFORM] DELETE vs TRUNCATE explanation
Previous:From: Sergey KonoplevDate: 2012-07-14 12:49:43
Subject: Re: Any tool/script available which can be used to measure scalability of an application's database.

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