Skip site navigation (1) Skip section navigation (2)

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:35:09
Message-ID: AANLkTi=kxEYgQKjs3NPtP2wQnMc4-3-7Gh-s3da=UnEK@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
Ahh, yes. In this case it is possibly only with holdable cursors by
declaring
them and committing before reading any rows from it to force materialization
of entire result set to the temporary storage.
Although, this approach can be used to avoid std::bad_alloc in case of
millions tuples in the result set :-)

2010/10/30 Dave Page <dpage(at)pgadmin(dot)org>

> On Sat, Oct 30, 2010 at 4:14 PM, Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
> wrote:
> > 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 ?
>
> No, I mean that the tool was developed to help tune application
> queries, in which the data transfer time can be just as important as
> the query execution time. With cursors, you lose that information.
>
> Of course, patches to make optional use of cursors would be interesting to
> us.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
// Dmitriy.

In response to

pgsql-general by date

Next:From: Jeff DavisDate: 2010-10-30 18:15:55
Subject: Re: gitweb error?
Previous:From: Dave PageDate: 2010-10-30 15:23:44
Subject: Re: Unhandled exception in PGAdmin when opening 16-million-record table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group