Re: Postgresql and multithreading

From: Doug McNaught <doug(at)wireboard(dot)com>
To: "D(dot) Hageman" <dhageman(at)dracken(dot)com>
Cc: Steve Wolfe <nw(at)codon(dot)com>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgresql and multithreading
Date: 2002-10-21 16:25:16
Message-ID: m3wuobsqs3.fsf@varsoon.wireboard.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"D. Hageman" <dhageman(at)dracken(dot)com> writes:

> This in many ways is a bogus argument in that 1) postgresql runs on more
> then just Linux and 2) amount of memmory that can be addressed by a
> process is tunable up to the point that it reaches a hardware limitation.

1) The OP specifically asked about Linux threads.
2) True up to a point--Linux (and most other Unices) reserve some
part of the VM address space for the kernel. On 64-bit this is a
non-issue, on 32-bit it's quite important now that you can put 4+GB
in a machine.

> It also should be noted that when a process reaches such a size that it
> better have a good reason. Now let us do a gedanken experiment and say
> you do have a good reason - fork a couple of these and your machine will
> thrash like nothing else ... also that whole hardware limitation will come
> into play more sooner then later ...

True enough. The only real use I can see for gobs of memory on a
32-bit PAE machine with PG is to give each process its own big hunk of
'sortmem' for doing large sorts. If you have 64 GB in the machine
setting 'sortmem' to 1GB or so starts to look reasonable...

-Doug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2002-10-21 16:27:20 Re: [GENERAL] Security implications of (plpgsql) functions
Previous Message Olivier PRENANT 2002-10-21 16:23:53 Re: Please help