Be able to set a page size for viewing a report different to the report overall record limit

[brendanheywood]

ie lets say I have a report with 1000 rows which is fairly small, I want to view that report in pages of 100.

Typically I want to err on the side of making the admin UI much faster and if I want the lot them I'll download the complete data, so the page limit only applies to the tablelib view.

[timhunt]

I don't want this. Seeing all the data just by scrolling is infinitely quicker (to a first approximation) than clicking and waiting for another page reload. The slow part of the page-view is executing the report.

[brendanheywood]

You are obviously dealing with different types of reports to what we often hit issue with. The UX can be plain terrible with 1000s of rows with many columns, the browser struggles to render it and it is all browser side dom rending which is the bottle neck and not server side bottle necks. Scrolling is a real pain and often you can't even scroll when the browser is locked up painting the page.

Would you be open to this landing as an opt in feature in some way and / or where the page size default it quite large or the same as the maximum?

[timhunt]

Which brower are you using? IE? Try Firefox.

[brendanheywood]

This is a common problem in both firefox and chrome. I haven't used IE let alone windows in at least a decade

[Peterburnett]

+1, attempting to log inspections on large data sets for forensics can be a big pain when pulling a large amount of rows. Page can start to use GBs of memory, and significantly slow down/die. Pagination for these instances would be a game changer, as opposed to limiting the query and constantly modifying it

[timhunt]

It seems like you are using this report for somethign compeltely different to us. (You seem to be using it for things where I would be using pgAdmin).

If you stick to what I think of as the Hippocratic Oath of open source development ("First do not hard") and come up with a well implemented patch which works for you, without causing any detriment to us, then I won't refuse to merge it.

(Acutally, additional select setting for each report, next to the row limit:

Page the results: [100, 1000, 10000, All on one page | v ]

with the last option as default, seems OK. Or, even, make 1000 the default for new reports, but make DB upgrade set all existing reports to 'All on one page'.)

[brendanheywood]

Ok thanks, what I think I'm proposing is:

1) There is a new admin setting which sets the default page size. If defaults to empty. If it is empty then there is no pagination 2) Each report has a new field for its page size, if it is empty, and the admin setting is empty there there is no pagination. 3) If the report value is empty, but the admin setting is set then it paginated 4) If it report value is set then it overrides the admin setting 5) Regardless of any pagination, the download is the full record set

Fresh installs and upgrades will behave exactly as they do now

Side note, yes there is a blurring of uses cases where pgAdmin might be a better tool, and we do use that locally, but in production that is a lot of unknowns around security and compliance and it's more hoops than we'd like so haven't gone that way.

[timhunt]

I don't think the admin setting is necessary, since you are writing the code, I won't stop you adding it.

I agree with all that, except point 3. If we have an admin setting, (Select menu with choices [100, 1000, 10000, 'No paging']), then I think the setting in the report should have choices ['System default (No paging)', 100, 1000, 10000, 'No paging'], Obviously, the first option changes depending on what the system default acutally is.

(And, up to you how you implement this, but obviously we can't use null for two things. I would use -1 at the report level to mean system default - with named constant to make the meaning clear.)

(Re last paragraph: yes, also I have beem know to use this plugin as a pgAdmin substitute at times.)

[brendanheywood]

Cool, I'm very flexi on those fine details, it's in the queue