Re: Question about memory allocations

From: Steve
Subject: Re: Question about memory allocations
Date: ,
Msg-id: Pine.GSO.4.64.0704122355360.17955@kittyhawk.tanabi.org
(view: Whole thread, Raw)
In response to: Re: Question about memory allocations  (Greg Smith)
List: pgsql-performance

Tree view

how to efficiently update tuple in many-to-many relationship?  (Drew Wilson, )
 Re: how to efficiently update tuple in many-to-many relationship?  ("Merlin Moncure", )
 Re: how to efficiently update tuple in many-to-many relationship?  (Tom Lane, )
  Re: how to efficiently update tuple in many-to-many relationship?  (Drew Wilson, )
   Re: how to efficiently update tuple in many-to-many relationship?  (Tom Lane, )
    Re: how to efficiently update tuple in many-to-many relationship?  (Drew Wilson, )
     Re: how to efficiently update tuple in many-to-many relationship?  (Tom Lane, )
      Re: how to efficiently update tuple in many-to-many relationship?  (Drew Wilson, )
       Re: how to efficiently update tuple in many-to-many relationship?  (Tom Lane, )
        Question about memory allocations  (Steve, )
         Re: Question about memory allocations  (Tom Lane, )
          Re: Question about memory allocations  (Steve, )
         Re: Question about memory allocations  (Greg Smith, )
          Re: Question about memory allocations  (Steve, )
         Re: Question about memory allocations  (Andrew McMillan, )
          Re: Question about memory allocations  (Steve, )
           Re: Question about memory allocations  (Ron, )
            Re: Question about memory allocations  (Tom Lane, )
           Re: Question about memory allocations  (Carlos Moreno, )
            Re: Question about memory allocations  ("Jan de Visser", )

> I didn't notice anyone address this for you yet.  There is a tool in
> contrib/pg_buffercache whose purpose in life is to show you what the shared
> buffer cache has inside it.  The documentation in that directory leads
> through installing it.  The additional variable you'll likely never know is
> what additional information is inside the operating system's buffer cache.

     Okay -- thanks!  I'll take a look at this.

>> # Leaving this low makes the DB complain, but I'm not sure what's #
>> reasonable.
>> checkpoint_segments = 128
>
> That's a reasonable setting for a large server.  The main downside to setting
> it that high is longer recovery periods after a crash, but I doubt that's a
> problem for you if you're so brazen as to turn off fsync.

     Hahaha yeah.  It's 100% assumed that if something goes bad we're
restoring from the previous day's backup.  However because the DB is read
only for -most- of the day and only read/write at night it's acceptable
risk for us anyway.  But good to know that's a reasonable value.


Steve


pgsql-performance by date:

From: "Avdhoot Kishore Saple"
Date:
Subject: local selectivity estimation - computing frequency of predicates
From: Tom Lane
Date:
Subject: Re: local selectivity estimation - computing frequency of predicates