Re: PATCH: Choose best width for Data Output columns of Query tool

Hi

On Sun, Dec 15, 2013 at 6:26 AM, J.F. Oster <jinfroster(at)mail(dot)ru> wrote:
> Hello Dave,
>
> Wednesday, December 11, 2013, 4:20:26 PM, you wrote:
>
> DP> I took a look at this, and my only real concern is that the
> DP> auto-sizing code is forcing the grid to fully populate itself, which
> DP> it's currently specifically designed not to. The result of this is
> DP> that if you have a large dataset, there is a delay between when the
> DP> query finishes and the results are rendered.
>
> DP> I would suggest that instead of looking at the first 50 rows, and then
> DP> looking at every 500th row until the end, we just look at the first
> DP> 500 and then stop. That won't be perfect of course, but it should
> DP> eliminate any delay with large amounts of data.
>
> I didn't know of that feature. I've changed the code as you suggested.
> Though the delay introduced here is hardly noticeable, afaics.
> Please see the fixed patch attached.

I could see it on a relatively new, and high-end MacBook, so I imagine
it would be even more noticeable on some other machines. Anyway -
thanks, patch applied!

> By the way, about viewing huge tables: a user would feel comfortable
> if he could setup the default limit for LIMIT clause in "Edit data"
> windows. Currently the user willing to see some table's data has first
> to notice it's rowcount and (if it is huge) instead of pressing "View
> data..." toobar button has to choose "View Data"->"View Top/Last 100
> Rows" from the table's context menu. Such effort is boring and takes
> time, especially when the user just wants to quickly see some sample
> data to "feel" the table's essence.
>
> I'd suggest adding a setting in Options dialogue, say "Default rows
> limit", defaulting itself to "No limit" to retain current behaviour.
> Please let me know if it is worth trying to implement this proposal.

Iirc, that's exactly why we added the Top/Last 100 rows feature. The
problem with the modification as you suggest is that we're bound to
end up with confused users that don't realise a limit was set (because
a colleague did it, or they did it and then forgot) who then mail us
asking why they only see 1000 rows. We'd need to make it very clear
that some rows were omitted somehow. If you can figure out a clear,
but non-intrusive way to do that, it might make sense.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company