Re: PATCH: Choose best width for Data Output columns of Query tool - Mailing list pgadmin-hackers

On Thu, Nov 21, 2013 at 8:03 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi,
>
>
> On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <jinfroster@mail.ru> wrote:
>>
>> Hello Dinesh,
>>
>> DK> Do
>> SELECT '1', 'f'; ==>> And then re-size the 1st
>> SELECT '1', 'f'; ==>> column to the end of the screen.
>> DK> Then do,
>> DK> SELECT 'f', '111111......Wide column' ==> This should re-size
>> DK> the grid as per the query result, which is not happening currently
>> DK> in my windows machine.
>> The first column gets same label in both queries
>> ("?column?\nunknown"). The original code behaves identically.
>>
>> DK> Note: Yours 1st patch is working fine with the above case.
>> Due to my inadvertence it didn't honour previously saved sizes at all.
>>
>> Here is another idea:
>> Do save the sizes only for those columns which were explicitly
>> resized by the user. Every user's resize results in new (or update to
>> existing) element in some associative array, whose key is composed of
>> colIndex and colLabel, and value is user-specified size. Elements
>> never get deleted out of this array for the life of Query window.
>> When displaying new result set, each column is inspected, if it's
>> index and label have corresponding element in array, it's size is
>> restored. Else it falls under automatic sizing.
>> Good points here:
>> 0. Automatic sizing works by default for every result set - so is
>> responsive (unlike last patch!) to changes in query results where
>> labels don't change - that's a very frequent case.
>> 1. Can save and restore user-specified sizes for columns in several
>> _different_ queries (run in the same window in arbitary order).
>> 2. Undesired sizing artefacts may appear in rare cases where user has
>> manually resized the column AND later he got column with same label
>> and in same position but of positively improper size (your last case
>> is about it). This still can be overcome by introducing restrictions
>> on applying saved sizes ("if saved and auto sizes differ more than n
>> times, discard the saved one / resize to something between / etc").
>>
>> I'll try to implement this approach soon.
>> Opinions are welcome!
>>
>
> This is a good approach. But i am worrying about the performance.
>
> For Ex:-
> What if the query is having two many columns in a table, which will be
> storing in a Hash/Assoc array, following by a SELECT query with a single
> column.
>
> @Dave,
>
> Could you share your inputs on this please.

I'd be inclined to drop the array as soon as we get a resultset back
with a different structure - otherwise, we'll do some weird sizing on
single columns which have very common names, but differing data
widths.

I'm not overly concerned about performance here - I can't see it using
vast amounts of memory or anything. Remember, every element in the
array would only get there because a user resized a column in this
session. I can't see the size of that getting beyond a few tens, or
maybe a hundred or so in the most extreme case.

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

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