> On 10/06/2011 00:14, Jehan-Guillaume (ioguix) de Rorthais wrote: >> Hello, >> >> I was wondering which other command I'll add in pgpool_adm so I focused >> on proc_info. >> >> But it occurs to me that using pcp_proc_info require to fetch one PID >> first, so you have 2 commands to executes. More if you want to get >> information about multi PID. >> >> On the other hand, returning pcp_proc_info for ALL existing procs might >> be a large set of data. But I do prefer piping a large set of data in >> "less", "dog" or "more" and searching there what I need, than typing >> many commands, playing with history. >> >> So what about adding as first parameter the pgpool PID and making this >> command return everything ? We can even keep reverse compatibility by >> considering the PID parameter as optional: return everything if no PID >> given, only informations about the PID if given. >> >> Moreover, from the pgpool_adm point of you, I don't think I'll need to >> hack the proc_count function, we will be able to get that information >> with a simple query like that: >> >> SELECT DISTINCT pid FROM pcp_proc_info(); >> >> ... We can even add this as a simple SQL function if we really want to >> have it in the module: >> CREATE FUNCTION pcp_proc_count() RETURNS SETOF integer AS $$ >> SELECT DISTINCT pid FROM pcp_proc_info(); >> $$ LANGUAGE SQL; >> >> Considering we could do the same kind of trick with the pcp binary >> command, if pcp_proc_info returns everything, I would advice to remove >> this from the protocol itself then. > > I was thinking we could actually do the same kind of work with > pcp_node_info and pcp_node_count... > >> Comments ?
Sounds nice idea for me. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
