FAQ
ISTM that before long someone will want to use more than 2 GB for work_mem.
Currently, you can't set more because it overflows the variable. I'm not
sure a wholesale switch of GUC integers to 64 bit is the solution. Maybe
changing some of the variables to reals would work. Comments?

Search Discussions

  • Tom Lane at Jul 25, 2006 at 4:02 pm

    Peter Eisentraut writes:
    ISTM that before long someone will want to use more than 2 GB for work_mem.
    Currently, you can't set more because it overflows the variable.
    Yes you can, because the value is measured in KB.

    Now, if you were to redefine it as being measured in bytes, you would
    have a backlash, because people already are using values above 2GB.
    I'm not sure a wholesale switch of GUC integers to 64 bit is the
    solution.
    I'd be fairly worried about whether that wouldn't mean we fail
    completely on INT64_IS_BROKEN platforms ...

    regards, tom lane
  • Peter Eisentraut at Jul 25, 2006 at 12:38 pm

    Am Dienstag, 25. Juli 2006 14:15 schrieb Tom Lane:
    Peter Eisentraut <peter_e@gmx.net> writes:
    ISTM that before long someone will want to use more than 2 GB for
    work_mem. Currently, you can't set more because it overflows the
    variable.
    Yes you can, because the value is measured in KB.
    Right, so there is probably a bug in my patch ... Nevermind then. All the
    other options are OK with 32 bit ints.
    I'd be fairly worried about whether that wouldn't mean we fail
    completely on INT64_IS_BROKEN platforms ...
    I wonder whether platforms with INT64_IS_BROKEN can address more than 2GB of
    memory anyway.
  • Tom Lane at Jul 25, 2006 at 2:55 pm

    Peter Eisentraut writes:
    Am Dienstag, 25. Juli 2006 14:15 schrieb Tom Lane:
    I'd be fairly worried about whether that wouldn't mean we fail
    completely on INT64_IS_BROKEN platforms ...
    I wonder whether platforms with INT64_IS_BROKEN can address more than 2GB of
    memory anyway.
    No, surely they can't (on all machines we support, "long" is at least as
    wide as a pointer, cf Datum). I'm just worried about whether normal GUC
    behavior would work at all on such a machine. We've so far tried to
    preserve "it works as long as you don't try to use values larger than
    2G" on such machines, and I'm not quite prepared to give that up.

    regards, tom lane
  • Josh Berkus at Jul 25, 2006 at 6:29 pm
    Peter,
    I wonder whether platforms with INT64_IS_BROKEN can address more than 2GB of
    memory anyway.
    To be quite frank, current PostgreSQL can't effectively use more than
    256mb of work_mem anyway. We'd like to fix that, but it's not fixed yet
    AFAIK.

    --Josh
  • Robert Treat at Jul 31, 2006 at 1:11 am

    On Tuesday 25 July 2006 14:28, Josh Berkus wrote:
    Peter,
    I wonder whether platforms with INT64_IS_BROKEN can address more than 2GB
    of memory anyway.
    To be quite frank, current PostgreSQL can't effectively use more than
    256mb of work_mem anyway. We'd like to fix that, but it's not fixed yet
    AFAIK.
    Josh, can you clarify this statement for me? Using work mem of higher than
    256MB is common practice in certain cases (db restore for example). Are you
    speaking in a high volume OLTP sense, or something beyond this?

    --
    Robert Treat
    Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
  • Tom Lane at Jul 31, 2006 at 1:25 am

    Robert Treat writes:
    On Tuesday 25 July 2006 14:28, Josh Berkus wrote:
    To be quite frank, current PostgreSQL can't effectively use more than
    256mb of work_mem anyway. We'd like to fix that, but it's not fixed yet
    AFAIK.
    Josh, can you clarify this statement for me?
    Perhaps I shouldn't put words in Josh' mouth, but I *think* what he
    meant is that the tuplesort code does not get any faster once work_mem
    exceeds a few hundred meg. I believe we've addressed that to some
    extent in CVS HEAD, but it's a fair gripe against the existing release
    branches.

    I'm not aware that anyone has done any work to characterize performance
    vs work_mem setting for any of the other uses of work_mem (such as hash
    table sizes).

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 25, '06 at 11:07a
activeJul 31, '06 at 1:25a
posts7
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase