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,
--
[EMAIL PROTECTED]
singh.gurjeet @{ gmail | hotmail | yahoo }.com
<patch_and_other_files.tar.gz>
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
