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

Поиск
Список
Период
Сортировка
От Dmitriy Igrishin
Тема Re: Unhandled exception in PGAdmin when opening 16-million-record table
Дата
Msg-id AANLkTi=8X_YXuy3jR9ixFiuF2vW6O9sM9Mwkr8XoAZc8@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unhandled exception in PGAdmin when opening 16-million-record table  (Dave Page <dpage@pgadmin.org>)
Ответы Re: Unhandled exception in PGAdmin when opening 16-million-record table  (Dave Page <dpage@pgadmin.org>)
Список 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.


В списке pgsql-general по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Which variant to choose?
Следующее
От: Dave Page
Дата:
Сообщение: Re: Unhandled exception in PGAdmin when opening 16-million-record table