Hi Gurjeet,
I will look at the pg_advise bug and will send a patch ASAP.
Best, Kai
Am 15.11.2006 um 15:34 schrieb Gurjeet Singh:
> BUGS:
> =====
> .) The SELECTs in the pg_advise are returning wrong results, when
> the same index is suggested twice, because of the SUM() aggregates.
> .) I doubt that on a table t(a,b), for a suggestion of idx(b,a),
> pg_advise will
> suggest idx(a,b);
>
> Wish-list:
> ==========
> .) Make pg_indexadvisor a user table.
> Reason: a normal user cannot do "delete from pg_indexadvisor".
> Difficulty: Need to know how to do
> "insert into pg_indexadvisor values( 1, ...)"
> from within the backend; that is, need to study/
> invent RSI
> (Recursive SQL Interface).
> Trial code can be seen by searching for:
> exec_simple_query( "insert into index_advisor values
> ( 10 )",
> "advisor" /*portal name*/ );
>
> .) Make it plugin-based.
> Reason: so that someone else with a better idea can replace
> this advisor, without having to recompile the server.
> Difficulty: This code calls many internal functoions:
> index_create(), index_drop(), planner(), etc.
> That makes it impossible to compile it standalone.
>
> .) Remove the dependency on the global "index_candidates"; used for
> communication between indexadvisor.c and plancat.c.
> Reason: Bad coding practice.
> Difficulty: Even though I was successful in updating
> pg_class.relpages for
> the virtual indexes, the planner is still calling
> smgr.c code to
> get the number of pages occupied by the index!
> Hence, I had to
> use the global the way I did.
>
> Best regards,
>
> --
> gurjeet[.singh]@EnterpriseDB.com
> singh.gurjeet @{ gmail | hotmail | yahoo }.com
> <patch_and_other_files.tar.gz>
