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 G
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 ou
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,
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 th
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,
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 t
