Hi, >> 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.
They are not what? What is slower - is the "display" part in both versions. You have data from server and than You push it to display. I've done quick test - table 650000 rows / 45 columns, query SELECT * from table limit 100000. With default ON_DEMAND_RECORD_COUNT around 5 seconds, with ON_DEMAND_RECORD_COUNT = 100000 25 seconds... It is 20 seconds spent only on displaying... >> 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. I don't know of any users (we are the users) who are happy that selecting 10000 rows requires dragging scrollbar five times to see 5001 record... Saying pointless I meant that if I want 10000 rows I should get 10000 rows, if I want to limit my data I'll use LIMIT. But if the ui can't handle big results just give me easiest/fastest way to get to may data. -- Tomek
