2013/11/12 Tom Lane <tgl@sss.pgh.pa.us>:
> 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).
>
Thanks for your comments. I assume this table-cache shall be applied
on tables that holds data set for analytic workloads. Even though it
may consume large amount of memory, it will hit its major workload
in this use scenario.
Probably, it will have upper limit of cache memory usage, and need
a mechanism to reclaim the cache block from the oldest one. Here
is nothing special. Also, even I call it "table cache", it is similar to
in-memory database being supported by rich memory hardware.
>> 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.
>
Yes, I understand it is not possible to submit whole of the patch until
CF3 deadline. So, I'd like to find out a way to implement it as an
extension using facilities being supported or to be enhanced on v9.4.
Best regards,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
