Re: [PATCHES] [HACKERS] [Fwd: Index Advisor]

It seems the size restriction has blocked my previous attempt. Please find
the first patch attached, and the second one will be in the next mail.

Best Regards,

--
gurjeet[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | yahoo }.com

On 1/13/07, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> wrote:
On 1/9/07, Gurjeet Singh < singh(dot)gurjeet(at)gmail(dot)com> wrote:
>
> Now that there's just one call to the Index Adviser (from planner()) we
> can now move forward in making it a plugin.

Hi All,

Please find attached two patches:

1) pg_post_planner_plugin-REL8_2_STABLE-v1.patch.gz
2) pg_index_adviser-REL8_2_STABLE-v26.patch.gz

Patch 1 introduces the infrastructure to call plugins from the tail-end of
the planner() function. The planner looks for a list of PPPFunctions
(PostPlannerPluginFunctions) in a rendezvous variable, and then calls the
'driver' callback into the plugin. This patch also adds a new function in
explain.c that can be used to generate a string similar to the output of the
EXPLAIN command. It also adds a harmless DLLIMPORT to some global variables
that were needed by the Index Adviser Plugin.

Patch 2 is the plugin version of the Index Adviser and the advise tool. It
creates two folders in the contrib module: pg_index_adviser and
pg_advise_index. The pg_index_adviser folder contains the updated README.
Both the folders contain their respective updated sample_*.[sql|txt] files.

Theres one point that needs attention in the patch 1. The code enclosed in
GLOBAL_CAND_LIST is a hack, which I couldn't get rid of. In plancat.c we
have two options to estimate the number of pages that would be occupied by a
virtual index:

i) Make a call back into the plugin to get the estimation. The code enabled
by GLOBAL_CAND_LIST implements this.

ii) We can allow the plugin to update the pg_class.relpages entry for each
virtual index, and the planner will pickup the values from there. The code
disabled by GLOBAL_CAND_LIST implements this.

Option (ii) would be ideal but the core members can be a better judge of
this. Is there any other way of doing this?

Best regards,

--
gurjeet[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | yahoo }.com