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
Robert Treat [EMAIL PROTECTED] 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
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?
--
Am Dienstag, 25. Juli 2006 14:15 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] 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.
Peter Eisentraut [EMAIL PROTECTED] 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
Peter Eisentraut [EMAIL PROTECTED] 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
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
