From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: What's needed for cache-only table scan? |
Date: | 2013-11-12 17:22:59 |
Message-ID: | CADyhKSVMonY+EgJHGKWhkOEO=OsjQHt065YwzGFHTH_ck64ymQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2013/11/12 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>> 2013/11/12 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> There's no possible way you'll finish this for 9.4.
>
>> 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.
>
> Oh! Okay, I misunderstood the context --- you meant this as an example
> use-case for the custom plan feature, right? Makes more sense now.
>
> I'm still dubious that it'd actually be very useful in itself, but it
> seems reasonable as a test case to make sure that a set of hooks for
> custom plans are sufficient to do something useful with.
>
Yes. I intend to put most of this table-caching feature on the custom-scan
APIs set, even though it may take additional hooks due to its nature,
independent from planner and executor structure.
So, are you thinking it is a feasible approach to focus on custom-scan
APIs during the upcoming CF3, then table-caching feature as use-case
of this APIs on CF4?
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-11-12 17:30:41 | Re: Possible memory leak with SQL function? |
Previous Message | J Smith | 2013-11-12 17:17:03 | Re: Errors on missing pg_subtrans/ files with 9.3 |