Re: Why should such a simple query over indexed columns be so slow?

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Alessandro Gagliardi <alessandro(at)path(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Why should such a simple query over indexed columns be so slow?
Date: 2012-01-30 21:45:34
Message-ID: CAOR=d=1bPJ1D=Mkfa+La_n_NPtOZQ9B6c+x7S4OmLDNYdLdOFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Jan 30, 2012 at 2:39 PM, Alessandro Gagliardi
<alessandro(at)path(dot)com> wrote:
> On Mon, Jan 30, 2012 at 1:25 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>
>> You can do "SHOW random_page_cost" yourself right now, too.
>>
> 4
>
> I also tried "SHOW seq_page_cost" and that's 1.
>
> Looking
> at http://www.postgresql.org/docs/current/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
> I wonder if I should try reducing random_page_cost?
>
> Something that might help when it comes to advice on performance tuning is
> that this database is used only for analytics. It's essentially a partial
> replication of a production (document-oriented) database. So a lot of normal
> operations that might employ a series of sequential fetches may not actually
> be the norm in my case. Rather, I'm doing a lot of counts on data that is
> typically randomly distributed.

Yes try lowering it. Generally speaking, random page cost should
always be >= seq page cost. Start with a number between 1.5 and 2.0
to start with and see if that helps. You can make it "sticky" for
your user or database with alter user or alter database...

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Alessandro Gagliardi 2012-01-30 21:45:35 Re: Why should such a simple query over indexed columns be so slow?
Previous Message Alessandro Gagliardi 2012-01-30 21:39:14 Re: Why should such a simple query over indexed columns be so slow?