Обсуждение: Set statement timeout in the query tool
Hi, Someone, on a french PostgreSQL forum, ask me for a statement timeout UI in the query tool. Here is what I've done so far: * add a config in the Query tab of the Options window; * add a textbox in the toolbar of the query tool; * each query executed will first get the old statement_timeout value, set statement_timeout to the text box one (which is initialized with the config value), execute the real query, and then get back to the old value I checked the UI on Windows, Mac OS X, and Linux. The patch is attached. Comments? -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Вложения
On Fri, Dec 4, 2009 at 9:41 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Hi, > > Someone, on a french PostgreSQL forum, ask me for a statement timeout UI in > the query tool. Here is what I've done so far: > > * add a config in the Query tab of the Options window; > * add a textbox in the toolbar of the query tool; We certainly don't need both. > * each query executed will first get the old statement_timeout value, set > statement_timeout to the text box one (which is initialized with the config > value), execute the real query, and then get back to the old value Why save/reset it? The next query will just change it again anyway, and there's no way round that. > I checked the UI on Windows, Mac OS X, and Linux. What's wrong with just setting it manually in the script anyway? There are various parameters people might want to set, that we definitely don't want to add UI for. I'll concede that statement_timeout is more likely to be used than most others, but it seems to me that forcing it to be set with every query is far less flexible than just setting it as and when required in your script. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Fri, Dec 4, 2009 at 10:52, Dave Page <dpage@pgadmin.org> wrote: > On Fri, Dec 4, 2009 at 9:41 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Hi, >> >> Someone, on a french PostgreSQL forum, ask me for a statement timeout UI in >> the query tool. Here is what I've done so far: >> >> * add a config in the Query tab of the Options window; >> * add a textbox in the toolbar of the query tool; > > We certainly don't need both. Definitely not. I'd go with just the textbox, if any. >> * each query executed will first get the old statement_timeout value, set >> statement_timeout to the text box one (which is initialized with the config >> value), execute the real query, and then get back to the old value > > Why save/reset it? The next query will just change it again anyway, > and there's no way round that. > >> I checked the UI on Windows, Mac OS X, and Linux. > > What's wrong with just setting it manually in the script anyway? There > are various parameters people might want to set, that we definitely > don't want to add UI for. I'll concede that statement_timeout is more > likely to be used than most others, but it seems to me that forcing it > to be set with every query is far less flexible than just setting it > as and when required in your script. I think the use-case is to have a default value for people who may otherwise send off a query that takes way too long? But in that case, it's probably better implemented as a default value on the server side, no? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, Dec 4, 2009 at 1:09 PM, Magnus Hagander <magnus@hagander.net> wrote: > I think the use-case is to have a default value for people who may > otherwise send off a query that takes way too long? But in that case, > it's probably better implemented as a default value on the server > side, no? If you decide something is taking too long, just hit the Stop button. I'm not sure I want a forced query timeout - I'd rather set one myself if I want to. I certainly don't want any queries (no matter how lightweight) to be added to my script when I hit Run. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Le vendredi 4 décembre 2009 à 10:52:33, Dave Page a écrit : > On Fri, Dec 4, 2009 at 9:41 AM, Guillaume Lelarge > > <guillaume@lelarge.info> wrote: > > Hi, > > > > Someone, on a french PostgreSQL forum, ask me for a statement timeout UI > > in the query tool. Here is what I've done so far: > > > > * add a config in the Query tab of the Options window; > > * add a textbox in the toolbar of the query tool; > > We certainly don't need both. > I see a use case for having both. If someone uses a lot the statement_timeout option, he'll be annoyed to put it in the text box every time he launches the query tool. You'll tell me that he can have a specific user option (with ALTER USER), and you'll be right. But many of my customers don't have specific user for their own connection (which is a bad habit, but also a difficult one to loose). > > * each query executed will first get the old statement_timeout value, > > set statement_timeout to the text box one (which is initialized with the > > config value), execute the real query, and then get back to the old value > > Why save/reset it? The next query will just change it again anyway, > and there's no way round that. > Because every other query launch by the query tool will use it. For example the one of the GQB (which, AFAIK, uses the same connection). > > I checked the UI on Windows, Mac OS X, and Linux. > > What's wrong with just setting it manually in the script anyway? Nothing, if you don't do this a lot. > There are various parameters people might want to set, that we definitely > don't want to add UI for. I'll concede that statement_timeout is more > likely to be used than most others, but it seems to me that forcing it > to be set with every query is far less flexible than just setting it > as and when required in your script. > I don't have any issues with adding a UI for other parameters (work_mem comes to mind immediately). We can put them all in their own toolbar, so that users can hide it, so that it doesn't cluter the window UI. Anyways I don't see a lot of parameters that would need that treatment. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Le vendredi 4 décembre 2009 à 14:17:01, Dave Page a écrit : > On Fri, Dec 4, 2009 at 1:09 PM, Magnus Hagander <magnus@hagander.net> wrote: > > I think the use-case is to have a default value for people who may > > otherwise send off a query that takes way too long? But in that case, > > it's probably better implemented as a default value on the server > > side, no? > > If you decide something is taking too long, just hit the Stop button. > I'm not sure I want a forced query timeout - I'd rather set one myself > if I want to. I certainly don't want any queries (no matter how > lightweight) to be added to my script when I hit Run. > Probably I did code too quickly. Rereading the thread with him, I have a better answer for this guy. This seems to be so easy to do, that I didn't take the time to think more, and just code it :) We should probably drop this patch. I'll keep it in its git branch, because I love the git branches and I hate losing something I wrote. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Fri, Dec 4, 2009 at 5:33 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > I see a use case for having both. If someone uses a lot the statement_timeout > option, he'll be annoyed to put it in the text box every time he launches the > query tool. Just save the value in the toolbar using sysSettings. >> Why save/reset it? The next query will just change it again anyway, >> and there's no way round that. >> > > Because every other query launch by the query tool will use it. For example > the one of the GQB (which, AFAIK, uses the same connection). Right - but you'd still only need to set it once, when the window is opened, or if the value is changed. There's no need to keep resetting it. > I don't have any issues with adding a UI for other parameters (work_mem comes > to mind immediately). We can put them all in their own toolbar, so that users > can hide it, so that it doesn't cluter the window UI. I do. Extra code maintenance and complexity for little gain. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > We should probably drop this patch. I'll keep it in its git branch, because I > love the git branches and I hate losing something I wrote. :-) Perhaps you should publish your git tree (or select branches from it) to git.postgresql.org? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Le vendredi 4 décembre 2009 à 18:43:47, Dave Page a écrit : > On Fri, Dec 4, 2009 at 5:33 PM, Guillaume Lelarge > > <guillaume@lelarge.info> wrote: > > I see a use case for having both. If someone uses a lot the > > statement_timeout option, he'll be annoyed to put it in the text box > > every time he launches the query tool. > > Just save the value in the toolbar using sysSettings. > Oh yes, I didn't think about that. Always thought that settings should all be in the Options window, even if it's possible to set them also elsewhere (examples are settings for the query tool). > >> Why save/reset it? The next query will just change it again anyway, > >> and there's no way round that. > > > > Because every other query launch by the query tool will use it. For > > example the one of the GQB (which, AFAIK, uses the same connection). > > Right - but you'd still only need to set it once, when the window is > opened, or if the value is changed. There's no need to keep resetting > it. > Right too. > > I don't have any issues with adding a UI for other parameters (work_mem > > comes to mind immediately). We can put them all in their own toolbar, so > > that users can hide it, so that it doesn't cluter the window UI. > > I do. Extra code maintenance and complexity for little gain. > Yes, sure. It's not really a complex functionality, but many minors make a complex one. I've asked Fabrice to give me more details. If it's more interesting this time, I'll probably come back with another (better?) patch. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Le vendredi 4 décembre 2009 à 18:44:29, Dave Page a écrit : > On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge > > <guillaume@lelarge.info> wrote: > > We should probably drop this patch. I'll keep it in its git branch, > > because I love the git branches and I hate losing something I wrote. > > > :-) > > Perhaps you should publish your git tree (or select branches from it) > to git.postgresql.org? > Sure, but I have no idea how to do this. Anyone care to explain? -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Sat, Dec 5, 2009 at 9:02 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le vendredi 4 décembre 2009 à 18:44:29, Dave Page a écrit : >> On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge >> >> <guillaume@lelarge.info> wrote: >> > We should probably drop this patch. I'll keep it in its git branch, >> > because I love the git branches and I hate losing something I wrote. >> > >> :-) >> >> Perhaps you should publish your git tree (or select branches from it) >> to git.postgresql.org? >> > > Sure, but I have no idea how to do this. Anyone care to explain? Not 100% sure myself, but I've used something like: ------ - Setup a local repo: git svn clone svn://svn.pgadmin.org/trunk/pgadmin3 PGADMIN-TRUNK cd PGADMIN-TRUNK git svn rebase - Add the public repo as a remote repository - something like: git remote add pggit git://git.postgresql.org/git/users/gleu/pgadmin.git (note that you should adjust the paths and name (pggit) as required, and you may need to use the -t <branch> option to specify the branches you want to push). - Push the changes from the local repo to the pg git repo: git push pggit ------ -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Le lundi 7 décembre 2009 à 10:41:09, Dave Page a écrit : > On Sat, Dec 5, 2009 at 9:02 PM, Guillaume Lelarge > > <guillaume@lelarge.info> wrote: > > Le vendredi 4 décembre 2009 à 18:44:29, Dave Page a écrit : > >> On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge > >> > >> <guillaume@lelarge.info> wrote: > >> > We should probably drop this patch. I'll keep it in its git branch, > >> > because I love the git branches and I hate losing something I wrote. > >> > > >> :-) > >> > >> Perhaps you should publish your git tree (or select branches from it) > >> to git.postgresql.org? > > > > Sure, but I have no idea how to do this. Anyone care to explain? > > Not 100% sure myself, but I've used something like: > I asked for a git repo (two in fact). I'll try your howto as soon as they are accepted. Thanks. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
2009/12/7 Guillaume Lelarge <guillaume@lelarge.info>: > Le lundi 7 décembre 2009 à 10:41:09, Dave Page a écrit : >> On Sat, Dec 5, 2009 at 9:02 PM, Guillaume Lelarge >> >> <guillaume@lelarge.info> wrote: >> > Le vendredi 4 décembre 2009 à 18:44:29, Dave Page a écrit : >> >> On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge >> >> >> >> <guillaume@lelarge.info> wrote: >> >> > We should probably drop this patch. I'll keep it in its git branch, >> >> > because I love the git branches and I hate losing something I wrote. >> >> > >> >> :-) >> >> >> >> Perhaps you should publish your git tree (or select branches from it) >> >> to git.postgresql.org? >> > >> > Sure, but I have no idea how to do this. Anyone care to explain? >> >> Not 100% sure myself, but I've used something like: >> > > I asked for a git repo (two in fact). I'll try your howto as soon as they are > accepted. Thanks. Approved, but changed - they're users/gleu/pgadmin and users/gleu/postgres now - you just requested them in the root :-P I also made your postgres repository a clone of the main postgresql one to start with, I hope that was ok. They'll both show up within an hour (I can never remember exactly how long the delay is) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
2009/12/7 Dave Page <dpage@pgadmin.org>: > On Sat, Dec 5, 2009 at 9:02 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le vendredi 4 décembre 2009 à 18:44:29, Dave Page a écrit : >>> On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge >>> >>> <guillaume@lelarge.info> wrote: >>> > We should probably drop this patch. I'll keep it in its git branch, >>> > because I love the git branches and I hate losing something I wrote. >>> > >>> :-) >>> >>> Perhaps you should publish your git tree (or select branches from it) >>> to git.postgresql.org? >>> >> >> Sure, but I have no idea how to do this. Anyone care to explain? > > Not 100% sure myself, but I've used something like: > > ------ > - Setup a local repo: > > git svn clone svn://svn.pgadmin.org/trunk/pgadmin3 PGADMIN-TRUNK > cd PGADMIN-TRUNK > git svn rebase > > - Add the public repo as a remote repository - something like: > > git remote add pggit git://git.postgresql.org/git/users/gleu/pgadmin.git That needs to be ssh:// instead of git:// if you want to be able to push to it. We don't support push over the git:// protocol. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le mardi 8 décembre 2009 à 20:27:13, Magnus Hagander a écrit : > 2009/12/7 Guillaume Lelarge <guillaume@lelarge.info>: > > Le lundi 7 décembre 2009 à 10:41:09, Dave Page a écrit : > >> On Sat, Dec 5, 2009 at 9:02 PM, Guillaume Lelarge > >> > >> <guillaume@lelarge.info> wrote: > >> > Le vendredi 4 décembre 2009 à 18:44:29, Dave Page a écrit : > >> >> On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge > >> >> > >> >> <guillaume@lelarge.info> wrote: > >> >> > We should probably drop this patch. I'll keep it in its git branch, > >> >> > because I love the git branches and I hate losing something I > >> >> > wrote. > >> >> > > >> >> :-) > >> >> > >> >> Perhaps you should publish your git tree (or select branches from > >> >> it) to git.postgresql.org? > >> > > >> > Sure, but I have no idea how to do this. Anyone care to explain? > >> > >> Not 100% sure myself, but I've used something like: > > > > I asked for a git repo (two in fact). I'll try your howto as soon as they > > are accepted. Thanks. > > Approved, but changed - they're users/gleu/pgadmin and > users/gleu/postgres now - you just requested them in the root :-P > Yeah. In fact, I find it a bit difficult to fill the form. I was not sure how to fill some of the fields. Anyways, thanks for your changes. And thanks for approving :) > I also made your postgres repository a clone of the main postgresql > one to start with, I hope that was ok. > That's OK too. Will work on pg_dump/pg_dumpall/pg_restore quite soon. > They'll both show up within an hour (I can never remember exactly how > long the delay is) > OK. I'll check. Thanks again. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Le mardi 8 décembre 2009 à 20:27:57, Magnus Hagander a écrit : > 2009/12/7 Dave Page <dpage@pgadmin.org>: > > On Sat, Dec 5, 2009 at 9:02 PM, Guillaume Lelarge > > > > <guillaume@lelarge.info> wrote: > >> Le vendredi 4 décembre 2009 à 18:44:29, Dave Page a écrit : > >>> On Fri, Dec 4, 2009 at 5:38 PM, Guillaume Lelarge > >>> > >>> <guillaume@lelarge.info> wrote: > >>> > We should probably drop this patch. I'll keep it in its git branch, > >>> > because I love the git branches and I hate losing something I wrote. > >>> > > >>> :-) > >>> > >>> Perhaps you should publish your git tree (or select branches from it) > >>> to git.postgresql.org? > >> > >> Sure, but I have no idea how to do this. Anyone care to explain? > > > > Not 100% sure myself, but I've used something like: > > > > ------ > > - Setup a local repo: > > > > git svn clone svn://svn.pgadmin.org/trunk/pgadmin3 PGADMIN-TRUNK > > cd PGADMIN-TRUNK > > git svn rebase > > > > - Add the public repo as a remote repository - something like: > > > > git remote add pggit git://git.postgresql.org/git/users/gleu/pgadmin.git > > That needs to be ssh:// instead of git:// if you want to be able to > push to it. We don't support push over the git:// protocol. > Done. Works great AFAICT. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com