On Wed, 2006-11-22 at 11:17 +0100, Markus Schaber wrote:
PostgreSQL 8.1 (and, back then, 7.4) have the tendency to underestimate
the costs of sort operations, compared to index scans.
The Backend allocates gigs of memory (we've set sort_mem to 1 gig), and
then starts spilling out more Gigs
Hi,
PostgreSQL 8.1 (and, back then, 7.4) have the tendency to underestimate
the costs of sort operations, compared to index scans.
The Backend allocates gigs of memory (we've set sort_mem to 1 gig), and
then starts spilling out more Gigs of temporary data to the disk. So the
execution gets - in
On Wed, Nov 22, 2006 at 11:17:23AM +0100, Markus Schaber wrote:
The Backend allocates gigs of memory (we've set sort_mem to 1 gig), and
then starts spilling out more Gigs of temporary data to the disk.
How much RAM is in the server? Remember that sort_mem is _per sort_, so if
you have multiple
Hi, Steinar,
Steinar H. Gunderson wrote:
On Wed, Nov 22, 2006 at 11:17:23AM +0100, Markus Schaber wrote:
The Backend allocates gigs of memory (we've set sort_mem to 1 gig), and
then starts spilling out more Gigs of temporary data to the disk.
How much RAM is in the server? Remember that
Hi, Frank,
Frank Wiles wrote:
The temporary data is not swapping, it's the Postgres on-disk sort
algorithm.
Are you actually running a query where you have a GB of data
you need to sort? If not I fear you may be causing the system
to swap by setting it this high.
Yes, the
On Wed, 22 Nov 2006 15:28:12 +0100
Markus Schaber [EMAIL PROTECTED] wrote:
Hi, Steinar,
Steinar H. Gunderson wrote:
On Wed, Nov 22, 2006 at 11:17:23AM +0100, Markus Schaber wrote:
The Backend allocates gigs of memory (we've set sort_mem to 1
gig), and then starts spilling out more Gigs
