Re: Allow sorts to use more available memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Schnabel <schnabelr(at)missouri(dot)edu>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Allow sorts to use more available memory
Date: 2011-09-12 23:20:22
Message-ID: 17895.1315869622@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Robert Schnabel <schnabelr(at)missouri(dot)edu> writes:
> On 9/12/2011 3:58 PM, Scott Marlowe wrote:
>> On Mon, Sep 12, 2011 at 11:33 AM, Robert Schnabel
>> <schnabelr(at)missouri(dot)edu> wrote:
>>> The recent "data warehouse" thread made me think about how I use work_mem
>>> for some of my big queries. So I tried SET work_mem = '4GB' for a session
>>> and got
>>> ERROR: 4194304 is outside the valid range for parameter "work_mem" (64 ..
>>> 2097151)

>> Ubuntu 10.10, pgsql 8.4.8:
>> smarlowe=# set work_mem='1000GB';
>> SET

> Ok, so is this a limitation related to the Windows implementation?

Yeah. If you look into guc.c you'll find this:

/* upper limit for GUC variables measured in kilobytes of memory */
/* note that various places assume the byte size fits in a "long" variable */
#if SIZEOF_SIZE_T > 4 && SIZEOF_LONG > 4
#define MAX_KILOBYTES INT_MAX
#else
#define MAX_KILOBYTES (INT_MAX / 1024)
#endif

Since Windows, more or less alone among known 64-bit operating systems,
chose not to make "long" the same width as pointers, these values get
restricted just as if you were on a 32-bit machine. Few Postgres
developers use Windows enough to get excited about doing all the tedious
(and bug-prone) gruntwork that would be required to fix this.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Hany ABOU-GHOURY 2011-09-12 23:28:48 Re: Databases optimization
Previous Message Marinos Yannikos 2011-09-12 23:11:12 Re: Sudden drop in DBb performance