Re: What's needed for cache-only table scan? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: What's needed for cache-only table scan?
Date
Msg-id 5643.1384268449@sss.pgh.pa.us
Whole thread Raw
In response to What's needed for cache-only table scan?  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: What's needed for cache-only table scan?  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> The cache-only table scan, being in subject line, is an alternative scan
> logic towards sequential scan if all the referenced columns are cached.

This seems like a pretty dubious idea to me --- you're talking about
expending large amounts of memory on a single-purpose cache, without
any clear way to know if the data will ever be used before it gets
invalidated (and the life expectancy of the cache doesn't sound like
it'd be very high either).

> I'd like to find out the best way to implement this table-caching
> mechanism within scope of v9.4 functionality set.

There's no possible way you'll finish this for 9.4.  Keep in mind that
CF3 starts Friday, and CF4 starts 2014-01-15, and project policy is that
major feature patches should arrive (in at least rough form) by CF3.
Even ignoring that policy, this is more than 2 months worth of work.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: ERROR during end-of-xact/FATAL
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation