Dear Tom,
> I like the pg_advisor idea a lot better.
>
> [...]
>
> In the third place, if we try to solve the problem by embedding checks
> here and there in the backend, we'll limit ourselves to checks that can
> be made with minimal impact on backend performance and complexity. And
> we'll be limiting the number of people who can contribute, because
> writing backend code is hard. An external tool would be a lot more
> approachable IMHO. The original suggestion for pg_advisor mentioned
> pluggable tests, which seems like the right kind of approach to me.
There is something I cannot visualise about the idea being discussed.
If the tool is "separate" from postgresql as first suggested, it would
mean that it should have its own interface? It would be a new command?
What about GUI such as pgadmin3 of pgaccess?
Or separate only mean that it is a "separate" function of the backend that
can be triggered by calling existing functions such as "EXPLAIN" or
"ANALYZE" or new ones such as "CHECK" or "ADVICE" or whatever.
The second idea seems more reasonnable to me, because it avoids having a
separate interface. So it means that it would be a new "module" of the
backend. It would also be possible to have both worlds, that is:
psql> CHECK DATABASE comics; or ANALYZE comics;...
WARNING: costly this, missing that
AND
shell> pg_advisor -h sablons -U calvin -d comics
WARNING: ....
If it is mainly in the backend, because pg_advisor will be easy to
implement then;-) If all the logic is outside in a pg_advisor program,
then you won't have psql/pgaccess/pgadmin3... views.
Also, I'm not sure that checks would be that easy to implement outside of
the backend. I think real the argument is not to have the stuff performed
"on the fly", but the backend seems the proper place anyway.
Anyway, from my "teacher" point a view, I think it would be great to have
some place to put warnings or advices, so even if it is outside, it is
better than nowhere;-)
Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr