Re: Query tool results in grid

From: "Edward Di Geronimo Jr(dot)" <edigeronimo(at)xtracards(dot)com>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
Cc: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Query tool results in grid
Date: 2006-02-21 03:02:55
Message-ID: 1398.67.83.175.202.1140490975.squirrel@67.83.175.202
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

> Andreas Pflug wrote:
>
> We're not talking about 10 times, but about exponentially rising times!

Even with a custom table implementation? I just tried a select * in the
query tool on a table with 87k rows in the query tool. It took 4 seconds
to run the query and 24 seconds to display it. I tried loading the same
table in the view data window, and it took about 4 seconds to load via a
stopwatch estimate. Scrolling was instantaneous. Regardless of the
accuaracy of a stopwatch estimate, it was far less than 24 seconds for the
data to load and me to scroll through it all.

>> This problem is partly alleviated by handing the double timing display,
> Not really. This is *the* major issue on the query tool.

I strongly disagree. The speed certainly isn't great, but it is managable.
Using a list instead of a grid is an issue that severely limits the
usefulness of the tool. It's fine when I'm doing development work, but
it's horrible for when someone steps into my office and asks me for a
random piece of data.

I do understand the speed issue though. I guess the speed issue would piss
off the new users, and scare some of them off before they understand the
problem. Whereas the clipboard issue just pisses off the people who've
already decided to use Postgres.

> We're here at the edge of an older discussion. I'm against pushing
> ctlSqlResult to do everything, while sacrificing other basics (as
> peripheral as speed :-) I do see the need for a sophisticated data
> manipulation tool, but to me that's finally not pgAdmin but an
> additional tool. to speak M$, you wouldn't use MSAccess to fire
> arbitrary queries, but use ISQLW, and use MSAccess for data manipulation.

I've never worked with Access, so I can't really comment, but my
impression of Access was that it was nothing like pgAdmin. pgAdmin is a
cross of SQL Server's Enterprise Manager and Query Analyzer. pgAdmin does
just about everything Query Analyzer does. The only significant difference
between the two is the horrible clipboard support for query results in
pgAdmin.

> You might try to enhance the View Data tool's clipboard facilities.

I already did that a few weeks ago. This work is largely based on that.
The usefulness of it is limited though compared to having the
functionality in the Query Tool.

> Please *dont* try to handle data retrieval different from what it is
> now. We do have the problem of long GUI updates, but we also have
> consistent behaviour on the libpq side, making it comparable to psql and
> so forth. This must remain guaranteed, so any cursor implementation is
> nonacceptable.

I assumed Dave meant to retrieve all the data into pgAdmin, store it in a
custom table object, and then only insert it into the grid control as
necessary. That sounds to me like it would satisfy everyone's concerns.

Ed

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message August Zajonc 2006-02-21 03:20:05 pgxs
Previous Message August Zajonc 2006-02-20 22:49:00 Small update to README.admin81