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

Re: [PERFORM] Question about CLUSTER

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: salman <salmanb(at)quietcaresystems(dot)com>, pgsql-novice(at)postgresql(dot)org, pgsql-admin(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Question about CLUSTER
Date: 2008-02-12 02:42:19
Message-ID: 20080212024219.GA42737@winnie.fuhr.org (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-novicepgsql-performance
On Mon, Feb 11, 2008 at 03:33:37PM -0600, Scott Marlowe wrote:
> On Feb 11, 2008 2:03 PM, salman <salmanb(at)quietcaresystems(dot)com> wrote:
> > I'm planning to cluster a few large tables in our database but I'm
> > unable to find any recommendations/documentation on best practices --
> > Mainly, whether it's better to use an index which has a higher idx_scan
> > value, a higher idx_tup_read value, or the higest idx_tup_fetch value.
> >
> > I'm assuming that idx_tup_read would probably be the best choice, but
> > want to get other opinions before proceeding.
> 
> If you've got two indexes that are both being hit a lot, it might be
> worth looking into their correlation, and if they get used a lot
> together, look at creating an index on both.
> 
> But I'd guess that idx_tup_read would be a good bet.

You might also consider the ratio idx_tup_read::float8 / idx_scan
to see which indexes access a lot of rows per scan.

-- 
Michael Fuhr

In response to

pgsql-novice by date

Next:From: Michael SwierczekDate: 2008-02-12 14:30:27
Subject: Re: Question regarding GROUP BY
Previous:From: AndreasDate: 2008-02-12 01:59:08
Subject: Re: Question regarding GROUP BY

pgsql-performance by date

Next:From: Linux GuruDate: 2008-02-12 08:32:29
Subject: Re: Update with Subquery Performance
Previous:From: Michael FuhrDate: 2008-02-12 01:00:13
Subject: Re: Questions about enabling SSL

pgsql-admin by date

Next:From: Peter ChildsDate: 2008-02-12 07:56:16
Subject: Re: 8.3.0 upgrade, confused by documentation
Previous:From: Tena SakaiDate: 2008-02-11 22:25:10
Subject: Re: 8.3.0 upgrade, confused by documentation

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