Le 29/10/2010 14:46, Guillaume Lelarge a écrit :
> Le 29/10/2010 13:52, Rob Richardson a écrit :
>> A customer was reviewing the database that supports the application we
>> have provided. One of the tables is very simple, but has over 16
>> million records. Here is the table's definition:
>>
>
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 res
On Sat, Oct 30, 2010 at 4:14 PM, Dmitriy Igrishin 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
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 o
On Sat, Oct 30, 2010 at 2:45 PM, Peter Geoghegan
wrote:
> On 30 October 2010 11:26, Dmitriy Igrishin wrote:
>> Hey all,
>>
>> Why not to use MVC approach by implementing a model, which uses, e.g.
>> scrollable cursors? I believe that wxWidgets supports MVC.
>
> I've seen that behaviour before in
On 30 October 2010 11:26, Dmitriy Igrishin wrote:
> Hey all,
>
> Why not to use MVC approach by implementing a model, which uses, e.g.
> scrollable cursors? I believe that wxWidgets supports MVC.
I've seen that behaviour before in similar applications, but it had a
major downside: the number of r
Hey all,
Why not to use MVC approach by implementing a model, which uses, e.g.
scrollable cursors? I believe that wxWidgets supports MVC.
2010/10/30 Peter Geoghegan
> On 29 October 2010 21:52, Rob Richardson
> wrote:
> > A customer was reviewing the database that supports the application we
>
On 29 October 2010 21:52, Rob Richardson wrote:
> A customer was reviewing the database that supports the application we have
> provided. One of the tables is very simple, but has over 16 million
> records. Here is the table's definition:
>
> CREATE TABLE feedback
> (
> charge integer,
> ela
Le 29/10/2010 13:52, Rob Richardson a écrit :
> A customer was reviewing the database that supports the application we
> have provided. One of the tables is very simple, but has over 16
> million records. Here is the table's definition:
>
> CREATE TABLE feedback
> (
> charge integer,
> elap
On Fri, 2010-10-29 at 15:02 -0600, Rob Sargent wrote:
> Not saying this excuses the crash necessarily or more importantly the
> poor error message. One might find a stack trace in the system error log?
>
Think probably ran out of memory. 16M records? Really?
JD
--
PostgreSQL.org Major Contri
This one aught to be good!
The tool is after all called "pgAdmin" rather that say "pgBrowser".
I think you have a "teaching opportunity" here. There is a feature for
getting the first N rows that might help (a lot). There is
query-by-example as well.
I can't really imagine the value of being ab
A customer was reviewing the database that supports the application we
have provided. One of the tables is very simple, but has over 16
million records. Here is the table's definition:
CREATE TABLE feedback
(
charge integer,
elapsed_time integer, -- number of elapsed minutes since data bega
12 matches
Mail list logo
