Re: Unhandled exception in PGAdmin when opening 16-million-record table

From: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, Rob Richardson <Rob(dot)Richardson(at)rad-con(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Unhandled exception in PGAdmin when opening 16-million-record table
Date: 2010-10-30 15:14:48
Message-ID: AANLkTi=8X_YXuy3jR9ixFiuF2vW6O9sM9Mwkr8XoAZc8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hey Peter, Dave

> I've seen that behaviour before in similar applications, but it had a
> > major downside: the number of rows returned was not known in advance
> > of scrolling down to the last one. So you couldn't visualise the size
> > of the record set based on the size and relative position of the
> > scrollbar.
>
Why not MOVE cursor to the end, then get number of ROWS
(PQcmdTuples) affected by the MOVE command, and finally MOVE the first
tuple to determine the number of returned rows?

> That is basically how it works (MVC), albeit without using cursors;
> for both the reason you state and because part of the point of the
> tool is to tune queries and using cursors to do that completely messes
> up any timings we might get.
>
Do you mean that cursors (regular, not holdable) live only inside a
transactions?
But it is possible to check transaction status from another part of pgAdmin
or
even make the window with result set modal ?

>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

--
// Dmitriy.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dave Page 2010-10-30 15:23:44 Re: Unhandled exception in PGAdmin when opening 16-million-record table
Previous Message Merlin Moncure 2010-10-30 14:43:27 Re: Which variant to choose?