Re: Performance issues of one vs. two split tables.

From: "John D(dot) Burger" <john(at)mitre(dot)org>
To: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Performance issues of one vs. two split tables.
Date: 2007-05-15 19:16:13
Message-ID: 8B2AE71A-6EA7-42E2-9283-63A46086DBC3@mitre.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>> Thus, if there are a whole bunch of columns on each table, the
>> data in
>> those extra columns (e.g. - all columns aside from "id", the one that
>> was asked for in the result set) will indeed be drawn into memory.
>
> Is that specific to Postgresql? From an outside perspective it just
> seems odd that potentially a large amount of data would be pulled off
> disk into memory that is never used. Perhaps there's an overriding
> reason for this.

Anything else would seem odd to me. Pulling a page into memory
typically has OS support, and is thus very fast. Picking and
choosing bits and pieces to read would be prohibitively slow.
Moreover, caching only those bits and pieces would require
complicated code to decide whether the cached data is relevant to the
next query. Validating cached data at the page level is much
simpler, and thus faster.

Or so I assume ...

- John D. Burger
MITRE

In response to

Browse pgsql-general by date

  From Date Subject
Next Message PFC 2007-05-15 19:20:53 Re: Performance issues of one vs. two split tables.
Previous Message Steve Atkins 2007-05-15 19:14:03 Re: Performance issues of one vs. two split tables.