Re: Two usability suggestions

On Fri, Aug 29, 2008 at 1:40 AM, Robins Tharakan <tharakan(at)gmail(dot)com> wrote:
> Hi All,
>
> I have been using PgAdmin for a while now and feel that the following two
> have been the most troubling issues with PgAdmin (when compared with
> something like MSAccess).
>
> 1. Limiting the default row-count in EditGrid to a given X: It doesn't
> really matter that the number be 100 or 1000, but inevitably I've seen
> people in office having to 'End Task' PgAdmin just because they clicked on
> the Grid-icon for a 4 million row table. Frankly, its happened quite a few
> times to me as well, and although it is avoidable, practically speaking,
> until we get a cursor based 'Page Down' support in EditGrid, I really wish
> if we could have a row-limiting support by default (which is changeable from
> the drop-down). Probably have this limit changeable in frmOption as well ?

It seems to me that the simple answer to this is to make the View Data
button a menu button (like the plugins one), which remembers the last
selection for use as the default. That way, you just use 'View top 100
rows' the first time round, and it becomes the default for the button
from then onwards (do you realise we have that as an option on the
context menu already?).

Patches welcome if you want to give that a bash :-)

> 2. PgAdmin becomes irresponsive waiting for a simple query to succeed: Its
> happened many a times that I have a large dump taking place (for e.g.
> Refresh of a large-Materialized-View running, which essentially is a DELETE
> FROM TABLE, along with a large query that regenerates the
> hundred-thousand-row table). Alongside this (in the main PgAdmin window) if
> I simply click on any other table/view/function, PgAdmin just gets stuck
> pulling this table's (or view's/or function's) structure from the database.
> Now frankly, many a times I don't really care as much for this item's
> structure as much as I wish that PgAdmin doesn't get stuck until that large
> query finishes in the parallel window. Moral: Whatever is running in the
> background, PgAdmin should at least be responsive to user commands.

Recent versions should have no such issues in the query tool (prior to
1.8.0 you could get some strange interactions between multiple query
tools). In other areas of the code, there may be UI unresponsiveness
during long queries as they are run synchronously (except in the
debugger). What probably needs to be done is to rewrite the main
browser, Edit Grid and Server Status dialogue to use asynchronous
queries. In the debugger we do this by having the query complete code
raise an event which then processes the results.

In the Server Status and Edit Grid I don't think this would
necessarily be too hard to do, but in the main browser I imagine it
would be a significant and complex task to get the basic functionality
working, and to handle corner cases which arise because you're
suddenly able to do other things whilst queries are running in the
background (for example, if you refresh a node, there may be
assumptions in the code that you cannot select a different node whilst
the refresh is happening).

I'm unlikely to get any spare cycles to do this myself in this release
cycle, but I'm happy to work with you or anyone else that wants to
give it a go.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com