From: | Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com> |
---|---|
To: | Alex Vinnik <alvinnik(dot)g(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Simple join doesn't use index |
Date: | 2013-01-29 16:19:19 |
Message-ID: | CAP_rwwmwjZh+UX2cFztR3wKeEQqnXW=kNx_XhrN2E76K5bxduA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Jan 29, 2013 at 8:24 AM, Alex Vinnik <alvinnik(dot)g(at)gmail(dot)com> wrote:
> On Mon, Jan 28, 2013 at 6:55 PM, Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com>wrote:
>
>>
>> do you know pgtune?
>> it's a good tool for starters, if you want a fast postgres and don't
>> really want to learn what's behind the scenes.
>>
> Yeah.. I came across pgtune but noticed that latest version dated
> 2009-10-29 http://pgfoundry.org/frs/?group_id=1000416 which is kind of
> outdated. Tar file has settings for pg 8.3. Is still relevant?
>
Yes, I'm sure it will not do anything bad to your config.
>
>> random_page_cost=1 might be not what you really want.
>> it would mean that random reads are as fast as as sequential reads, which
>> probably is true only for SSD
>>
> What randon_page_cost would be more appropriate for EC2 EBS Provisioned
> volume that can handle 2,000 IOPS?
>
>>
>>
I'd say: don't guess. Measure.
Use any tool that can test sequential disk block reads versus random disk
block reads.
bonnie++ is quite popular.
Filip
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-01-29 16:41:47 | Re: Simple join doesn't use index |
Previous Message | Alex Vinnik | 2013-01-29 14:41:50 | Re: Simple join doesn't use index |