| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Auto-tuning work_mem and maintenance_work_mem |
| Date: | 2014-02-17 14:48:03 |
| Message-ID: | 16030.1392648483@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> writes:
> On 17/02/14 15:26, Robert Haas wrote:
>> I don't really know about cpu_tuple_cost. Kevin's often advocated
>> raising it, but I haven't heard anyone else advocate for that. I
>> think we need data points from more people to know whether or not
>> that's a good idea in general.
> Processors have been getting faster, relative to spinning rust, over the
> years. So it puzzles me why anybody would want to raise the
> cpu_tuple_cost!
The case where this is sensible is where your database mostly fits in
RAM, so that the cost of touching the underlying spinning rust isn't
so relevant. The default cost settings are certainly not very good
for such scenarios.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-02-17 14:58:15 | Re: narwhal and PGDLLIMPORT |
| Previous Message | Andres Freund | 2014-02-17 14:29:47 | Re: CREATE FOREIGN TABLE ( ... LIKE ... ) |