From: | George Essig <george_essig(at)yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Oleg Lebedev <oleg(dot)lebedev(at)waterford(dot)org>, Mary Edie Meredith <maryedie(at)osdl(dot)org>, Jenny Zhang <jenny(at)osdl(dot)org>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: TPC-R benchmarks |
Date: | 2003-10-01 16:55:53 |
Message-ID: | 20031001165553.22593.qmail@web80215.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> When benchmarking with data sets considerably larger than available
> buffer cache, I rather doubt that small random_page_cost would be a
> good idea. Still, you might as well experiment to see.
From experience, I know the difference in response time can be huge when postgres incorrectly
chooses a sequential scan over an index scan. In practice, do people experience as great a
difference when postgres incorrectly chooses an index scan over a sequential scan? My intuition
is that the speed difference is a lot less for incorrectly choosing an index scan. If this is the
case, it would be safer to chose a small value for random_page_cost.
George Essig
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-10-01 17:08:50 | Re: TPC-R benchmarks |
Previous Message | Oleg Lebedev | 2003-10-01 16:51:52 | Re: Tuning/performance issue... |