| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | gnuoytr(at)rcn(dot)com |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: How does PG know if data is in memory? |
| Date: | 2010-10-12 12:34:23 |
| Message-ID: | AANLkTinhh5mh3DK3+0ULtLUoAzuwd8BbYxLOUkcohQ26@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Oct 11, 2010 at 11:11 PM, <gnuoytr(at)rcn(dot)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/bufferpool match 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 structure at 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-10-12 12:36:24 | Re: Runtime dependency from size of a bytea field |
| Previous Message | Mladen Gogala | 2010-10-12 12:27:26 | Re: Slow count(*) again... |