Re: How does PG know if data is in memory? - Mailing list pgsql-performance

From
Subject Re: How does PG know if data is in memory?
Date
Msg-id 20101012102019.ANC95779@ms14.lnh.mail.rcn.net
Whole thread Raw
In response to Re: How does PG know if data is in memory?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-performance
The discussions I've seen indicated that, in use, tablespaces were at the database level, but, yes, the docs do say
thata table can be assigned to a defined tablespace.  What I still can't find is syntax which establishes
buffers/caches/whateverand assigns them to tablespaces.  Without that, I'm not sure what benefit there is to
tablespaces,other than a sort of RAID-lite. 

Robert


---- Original message ----
>Date: Tue, 12 Oct 2010 08:34:23 -0400
>From: pgsql-performance-owner@postgresql.org (on behalf of Robert Haas <robertmhaas@gmail.com>)
>Subject: Re: [PERFORM] How does PG know if data is in memory?
>To: gnuoytr@rcn.com
>Cc: pgsql-performance@postgresql.org
>
>On Mon, Oct 11, 2010 at 11:11 PM,  <gnuoytr@rcn.com> wrote:
>> An approach that works can be found in DB2, and likely elsewhere.
>>
>> The key is that tablespaces/tables/indexes/buffers are all attached through the bufferpool (the DB2 term).  A
tablespace/bufferpoolmatch is defined.  Then tables and indexes are assigned to the tablespace (and implicitly, the
bufferpool). As a result, one can effectively pin data in memory.  This is very useful, but not low hanging fruit to
implement.
>>
>> The introduction of rudimentary tablespaces is a first step.  I assumed that the point was to get to a DB2-like
structureat some point.  Yes? 
>
>We already have tablespaces, and our data already is accessed through
>the buffer pool.
>
>--
>Robert Haas
>EnterpriseDB: http://www.enterprisedb.com
>The Enterprise PostgreSQL Company
>
>--
>Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance

pgsql-performance by date:

Previous
From: Mladen Gogala
Date:
Subject: Re: Slow count(*) again...
Next
From: Joe Uhl
Date:
Subject: Re: Slow count(*) again...