On Tue, Oct 17, 2017 at 10:51 AM, Tomek <to...@apostata.org> wrote: > Hi, > > > As I mentioned in my previous email that we do not use server side > cursor, so it won't add any > > limit on query. > > > > The delay is from database driver itself, it has nothing to do with > pgAdmin4. > > Try executing the same query in 'psql', 'pgAdmin3' and third party tool > which use libpq library as > > backend, you will observe the same behaviour. > > It is not exactly truth... In v3 the query is executed, fetched and all > rows are displayed,
No they're not, though they are all transferred to the client which is why it's slower. > For me this idea of "load on demand" (which in reality is "display on demand") is pointless. It is done only because the main lag of v4 comes from interface. I don't see any other purpose for it... If You know (and You do) that v4 can't handle > big results add pagination like every other webapp... We did that in the first beta, and users overwhelmingly said they didn't like or want pagination. What we have now gives users the interface they want, and presents the data to them quickly - far more quickly than pgAdmin 3 ever did when working with larger resultsets. If that's pointless for you, then that's fine, but other users appreciate the speed and responsiveness. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
