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

Hi All,

Please see the attached patch.
It makes use of wxGrid's AutoSizeColumns() and applies some reasonable
limits afterwards. Works nicely in most scenarios I could imagine.
Tested with wxWidgets 2.8.12 on Ubuntu Linux.

Possibly this code should be moved to some procedure and triggered
from on-resize event handler as well?
Also it would be nice to have same behavior in "Edit Data" window
(ctlSQLEditGrid). But I'm new to wxWidgets... so please let me know
how to implement that better.
Thanks!


P.S. My company is moving from Oracle and a perfect IDE called "PL/SQL
Developer" (by allroundautomations.com) to PostgreSQL and pgAdmin III.
Having used pgAdmin years before, I see it gaining functionality to
support fast-growing PostgreSQL's features (great job!) but not
usability that well. Hope I can work on that (as far as I can :))

--
Best regards,
 Vadim

Dinesh, can you review this please? In particular, please check it
retains the column sizes following refresh if the user has customised
them, and that it puts a limit on the size of very long columns so the
user doesn't potentially end up with extremely wide columns that
require excessive scrolling (I would suggest that a column should
never take up more than 50% of the visible space, unless that space
would otherwise be unused (e.g. you have 1 very narrow column, and one
large).

Thanks.

On Sun, Nov 17, 2013 at 6:41 PM, J.F. Oster <jinfroster@mail.ru> wrote:
> Hi All,
>
> Please see the attached patch.
> It makes use of wxGrid's AutoSizeColumns() and applies some reasonable
> limits afterwards. Works nicely in most scenarios I could imagine.
> Tested with wxWidgets 2.8.12 on Ubuntu Linux.
>
> Possibly this code should be moved to some procedure and triggered
> from on-resize event handler as well?
> Also it would be nice to have same behavior in "Edit Data" window
> (ctlSQLEditGrid). But I'm new to wxWidgets... so please let me know
> how to implement that better.
> Thanks!
>
>
> P.S. My company is moving from Oracle and a perfect IDE called "PL/SQL
> Developer" (by allroundautomations.com) to PostgreSQL and pgAdmin III.
> Having used pgAdmin years before, I see it gaining functionality to
> support fast-growing PostgreSQL's features (great job!) but not
> usability that well. Hope I can work on that (as far as I can :))
>
> --
> Best regards,
>  Vadim
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>



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

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

Hello Dinesh,

DK> Could you check the following thing in your development machine.
>>> After applying your patch, i am not able to re-size the grid
>>> columns in windows 7 (64-bit) machine.
That possibly was a wide column that didn't want to shorten?
Ok, I changed AutoSizeColumns(bool setAsMin = true) to false.

DP> please check it retains the column sizes following refresh if the
DP> user has customised them,
I missed this, but now it should work as it did before.

DP> I would suggest that a column should never take up more than 50%
DP> of the visible space, unless that space would otherwise be unused
That's exactly what is done :)

Please see the modified patch attached.
Thanks.







Tuesday, November 19, 2013, 4:35:05 PM, you wrote:

DK> On Tue, Nov 19, 2013 at 2:38 PM, Dave Page <dpage@pgadmin.org> wrote:
DK> Dinesh, can you review this please? In particular, please check it
DK> retains the column sizes following refresh if the user has customised
DK> them, and that it puts a limit on the size of very long columns so the
DK> user doesn't potentially end up with extremely wide columns that
DK> require excessive scrolling (I would suggest that a column should
DK> never take up more than 50% of the visible space, unless that space
DK> would otherwise be unused (e.g. you have 1 very narrow column, and one
DK> large).

DK> Thanks.

DK> On Sun, Nov 17, 2013 at 6:41 PM, J.F. Oster <jinfroster@mail.ru> wrote:
>> Hi All,
>>
>> Please see the attached patch.
>> It makes use of wxGrid's AutoSizeColumns() and applies some reasonable
>> limits afterwards. Works nicely in most scenarios I could imagine.
>> Tested with wxWidgets 2.8.12 on Ubuntu Linux.
>>
>> Possibly this code should be moved to some procedure and triggered
>> from on-resize event handler as well?
>> Also it would be nice to have same behavior in "Edit Data" window
>> (ctlSQLEditGrid). But I'm new to wxWidgets... so please let me know
>> how to implement that better.
>> Thanks!
>>
>>
>> P.S. My company is moving from Oracle and a perfect IDE called "PL/SQL
>> Developer" (by allroundautomations.com) to PostgreSQL and pgAdmin III.
>> Having used pgAdmin years before, I see it gaining functionality to
>> support fast-growing PostgreSQL's features (great job!) but not
>> usability that well. Hope I can work on that (as far as I can :))

--
Best regards,
  Vadim

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!




Wednesday, November 20, 2013, 12:16:31 PM, you wrote:

DK> Hello,


DK> Thanks for fixing this case as per my previous comments.


DK> Could you also check one more case with the latest submitted patch.


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.


DK> Note: Yours 1st patch is working fine with the above case.


DK> Thanks for your time and excellent support.



DK> Dinesh

DK> -- 
DK> Dinesh Kumar
DK> Software Engineer


DK> Ph: +918087463317

DK> Skype ID: dinesh.kumar432

DK> www.enterprisedb.com

DK> Follow us on Twitter
DK> @EnterpriseDB 

DK> Visit EnterpriseDB for tutorials, webinars, whitepapers and more




DK> On Wed, Nov 20, 2013 at 12:06 PM, Dinesh Kumar
DK> <dinesh.kumar@enterprisedb.com> wrote:
DK> Thanks for fixing.

DK> Let me look into this.



DK> Dinesh

DK> -- 
DK> Dinesh Kumar
DK> Software Engineer


DK> Ph: +918087463317

DK> Skype ID: dinesh.kumar432

DK> www.enterprisedb.com

DK> Follow us on Twitter
DK> @EnterpriseDB 

DK> Visit EnterpriseDB for tutorials, webinars, whitepapers and more





DK> On Tue, Nov 19, 2013 at 10:49 PM, J.F. Oster <jinfroster@mail.ru> wrote:
DK> Hello Dinesh,

DK>> Could you check the following thing in your development machine.
>>>> After applying your patch, i am not able to re-size the grid
>>>> columns in windows 7 (64-bit) machine.

DK> That possibly was a wide column that didn't want to shorten?
DK> Ok, I changed AutoSizeColumns(bool setAsMin = true) to false.

DP>> please check it retains the column sizes following refresh if the
DP>> user has customised them,
DK> I missed this, but now it should work as it did before.

DP>> I would suggest that a column should never take up more than 50%
DP>> of the visible space, unless that space would otherwise be unused
DK> That's exactly what is done :)

DK> Please see the modified patch attached.
DK> Thanks.







DK> Tuesday, November 19, 2013, 4:35:05 PM, you wrote:

DK>> On Tue, Nov 19, 2013 at 2:38 PM, Dave Page <dpage@pgadmin.org> wrote:
DK>> Dinesh, can you review this please? In particular, please check it
DK>> retains the column sizes following refresh if the user has customised
DK>> them, and that it puts a limit on the size of very long columns so the
DK>> user doesn't potentially end up with extremely wide columns that
DK>> require excessive scrolling (I would suggest that a column should
DK>> never take up more than 50% of the visible space, unless that space
DK>> would otherwise be unused (e.g. you have 1 very narrow column, and one
DK>> large).

DK>> Thanks.

DK>> On Sun, Nov 17, 2013 at 6:41 PM, J.F. Oster <jinfroster@mail.ru> wrote:
>>> Hi All,
>>>
>>> Please see the attached patch.
>>> It makes use of wxGrid's AutoSizeColumns() and applies some reasonable
>>> limits afterwards. Works nicely in most scenarios I could imagine.
>>> Tested with wxWidgets 2.8.12 on Ubuntu Linux.
>>>
>>> Possibly this code should be moved to some procedure and triggered
>>> from on-resize event handler as well?
>>> Also it would be nice to have same behavior in "Edit Data" window
>>> (ctlSQLEditGrid). But I'm new to wxWidgets... so please let me know
>>> how to implement that better.
>>> Thanks!
>>>
>>>
>>> P.S. My company is moving from Oracle and a perfect IDE called "PL/SQL
>>> Developer" (by allroundautomations.com) to PostgreSQL and pgAdmin III.
>>> Having used pgAdmin years before, I see it gaining functionality to
>>> support fast-growing PostgreSQL's features (great job!) but not
>>> usability that well. Hope I can work on that (as far as I can :))


--
Best regards,
 Vadim

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

Hello Dinesh,

Please have a look at this version.

At first I've done it all as planned. Then I wanted a user to be able
to remove a column from array (switch back to auto-sizing). Clicking
on column's label seems good way to achieve that. And then I came
across ctlSQLGrid::OnLabelDoubleClick, which implements some column's
sizing for ctlSQLResult and ctlSQLEditGrid. As I was planning
auto-sizing feature for both "Query tool" and "Edit data" windows, I
decided to move new code into ctlSQLGrid and do it all at once.

Double-clicking a column's label with Ctrl pressed switches a
column back to auto-sizing. Without Ctrl the behavior is same as
before (toggling between several predefined scales?) + saving them to
array as manually specified.

Explain command's raw output column is also auto-sized now, I hope
it will be better than before on small screens.

Also I've noticed a slowdown in wxGrid::AutoSizeColumns() with large
result sets, and implemented it with some "optimization", see comments
in ctlSQLGrid::AutoSizeColumns().

Everything turned out fine except a problem in
frmEditGrid::Go() (frmEditGrid.cpp:1468)
  sqlGrid->SetSize(10, 10);
This hack makes auto-sizing choose very small widths.
I couldn't see any changes with it commented out (Linux). Is it still
required? If yes,
it's comment says:
> later, we will resize the grid's parent to force the correct size
I could call sqlGrid->AutoSizeColumns() after, but didn't find
the place where that resizing is done.




Thursday, November 21, 2013, 12:03:04 PM, you wrote:

DK> Hi,


DK> On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <jinfroster@mail.ru> wrote:
DK> 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.
DK> The first column gets same label in both queries
DK> ("?column?\nunknown"). The original code behaves identically.

DK>> Note: Yours 1st patch is working fine with the above case.
DK> Due to my inadvertence it didn't honour previously saved sizes at all.

DK> Here is another idea:
DK> Do save the sizes only for those columns which were explicitly
DK> resized by the user. Every user's resize results in new (or update to
DK> existing) element in some associative array, whose key is composed of
DK> colIndex and colLabel, and value is user-specified size. Elements
DK> never get deleted out of this array for the life of Query window.
DK> When displaying new result set, each column is inspected, if it's
DK> index and label have corresponding element in array, it's size is
DK> restored. Else it falls under automatic sizing.
DK> Good points here:
DK> 0. Automatic sizing works by default for every result set - so is
DK> responsive (unlike last patch!) to changes in query results where
DK> labels don't change - that's a very frequent case.
DK> 1. Can save and restore user-specified sizes for columns in several
DK> _different_ queries (run in the same window in arbitary order).
DK> 2. Undesired sizing artefacts may appear in rare cases where user has
DK> manually resized the column AND later he got column with same label
DK> and in same position but of positively improper size (your last case
DK> is about it). This still can be overcome by introducing restrictions
DK> on applying saved sizes ("if saved and auto sizes differ more than n
DK> times, discard the saved one / resize to something between / etc").

DK> I'll try to implement this approach soon.
DK> Opinions are welcome!





DK> This is a good approach. But i am worrying about the performance.

DK> For Ex:-
DK> What if the query is having two many columns in a table,
DK> which will be storing in a Hash/Assoc array, following by a SELECT
DK> query with a single column.


DK> @Dave,


DK> Could you share your inputs on this please.


DK> Thanks,
DK> Dinesh



--
Best regards,
 Vadim

Hello Dinesh,

Monday, December 2, 2013, 4:30:18 PM, you wrote:

DK> Are you saying like double click on column header while
DK> holding "CTRL" in keyboard. If so, in mac i have tried it with
DK> "control" and "command" buttons, which is not working.

Yes. I'm not familiar with Mac... but some googling gave this:
>Use CmdDown if you want to test for either the Meta key (on Mac OS X)
>or the Control key (other platforms)
So changed it to event.CmdDown().
By the way, event.ControlDown() is used in ctlSQLGrid::OnMouseWheel()
to adjust font size - I assume it also needs to be changed.

DK> 1. Use wxRound() rather than round(). We don't have round() in windows. :(  
DK>     Or use an integer value for pointing rows.

Oops. I'll use wxRound(). Float is there intentionally to achieve
irregular loop step.

DK> 2. Could you implement the same as below if possible. Since,
DK> while performing double click on a column, i am getting noticeable
DK> delay.

==>>While creating the grid it self, store each fields max length in a custom variable.
==>>Do AutoSizeColumns() Based on this max length, column header length.

Ok, now in AutoSizeColumns() I save max column sizes to colMaxSizes
array which will be used in AutoSizeColumn() and OnLabelDoubleClick()
without looping through rows again.

Please see the fixed patch attached.



DK> Thursday, November 21, 2013, 12:03:04 PM, you wrote:

DK>> Hi,


DK>> On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <jinfroster@mail.ru> wrote:
DK>> 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.

DK>> The first column gets same label in both queries
DK>> ("?column?\nunknown"). The original code behaves identically.

DK>>> Note: Yours 1st patch is working fine with the above case.

DK>> Due to my inadvertence it didn't honour previously saved sizes at all.

DK>> Here is another idea:
DK>> Do save the sizes only for those columns which were explicitly
DK>> resized by the user. Every user's resize results in new (or update to
DK>> existing) element in some associative array, whose key is composed of
DK>> colIndex and colLabel, and value is user-specified size. Elements
DK>> never get deleted out of this array for the life of Query window.
DK>> When displaying new result set, each column is inspected, if it's
DK>> index and label have corresponding element in array, it's size is
DK>> restored. Else it falls under automatic sizing.
DK>> Good points here:
DK>> 0. Automatic sizing works by default for every result set - so is
DK>> responsive (unlike last patch!) to changes in query results where
DK>> labels don't change - that's a very frequent case.
DK>> 1. Can save and restore user-specified sizes for columns in several
DK>> _different_ queries (run in the same window in arbitary order).
DK>> 2. Undesired sizing artefacts may appear in rare cases where user has
DK>> manually resized the column AND later he got column with same label
DK>> and in same position but of positively improper size (your last case
DK>> is about it). This still can be overcome by introducing restrictions
DK>> on applying saved sizes ("if saved and auto sizes differ more than n
DK>> times, discard the saved one / resize to something between / etc").

DK>> I'll try to implement this approach soon.
DK>> Opinions are welcome!





DK>> This is a good approach. But i am worrying about the performance.

DK>> For Ex:-
DK>> What if the query is having two many columns in a table,
DK>> which will be storing in a Hash/Assoc array, following by a SELECT
DK>> query with a single column.


DK>> @Dave,


DK>> Could you share your inputs on this please.





--
Best regards,
 Vadim

Hello Dinesh,

Tuesday, December 3, 2013, 12:23:16 PM, you wrote:


DK> Could you change this like "event.CmdDown()
DK> || event.CtrlDown()" for supporting both Mac, as well non-mac
DK> keyboards.

Done.

DK> I believe, the column size should not exceed to the half of
DK> the available screen. But in this patch, the column size grows to
DK> end of the screen.

That is by design, as we have no reason to refuse to benefit of
user's wide screen if all other columns fit well. Also Dave's
observations were the same:
Tuesday, November 19, 2013, 1:08:17 PM, Dave Page wrote:
DP> ...
DP> (I would suggest that a column should
DP> never take up more than 50% of the visible space, unless that space
DP> would otherwise be unused (e.g. you have 1 very narrow column, and one
DP> large).


DK> And also suggesting to change the AutoColumns() function like below.

Sure, done.

Please see the fixed patch attached.




DK>> Thursday, November 21, 2013, 12:03:04 PM, you wrote:

DK>>> Hi,


DK>>> On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <jinfroster@mail.ru> wrote:
DK>>> 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.

DK>>> The first column gets same label in both queries
DK>>> ("?column?\nunknown"). The original code behaves identically.

DK>>>> Note: Yours 1st patch is working fine with the above case.

DK>>> Due to my inadvertence it didn't honour previously saved sizes at all.

DK>>> Here is another idea:
DK>>> Do save the sizes only for those columns which were explicitly
DK>>> resized by the user. Every user's resize results in new (or update to
DK>>> existing) element in some associative array, whose key is composed of
DK>>> colIndex and colLabel, and value is user-specified size. Elements
DK>>> never get deleted out of this array for the life of Query window.
DK>>> When displaying new result set, each column is inspected, if it's
DK>>> index and label have corresponding element in array, it's size is
DK>>> restored. Else it falls under automatic sizing.
DK>>> Good points here:
DK>>> 0. Automatic sizing works by default for every result set - so is
DK>>> responsive (unlike last patch!) to changes in query results where
DK>>> labels don't change - that's a very frequent case.
DK>>> 1. Can save and restore user-specified sizes for columns in several
DK>>> _different_ queries (run in the same window in arbitary order).
DK>>> 2. Undesired sizing artefacts may appear in rare cases where user has
DK>>> manually resized the column AND later he got column with same label
DK>>> and in same position but of positively improper size (your last case
DK>>> is about it). This still can be overcome by introducing restrictions
DK>>> on applying saved sizes ("if saved and auto sizes differ more than n
DK>>> times, discard the saved one / resize to something between / etc").

DK>>> I'll try to implement this approach soon.
DK>>> Opinions are welcome!





DK>>> This is a good approach. But i am worrying about the performance.

DK>>> For Ex:-
DK>>> What if the query is having two many columns in a table,
DK>>> which will be storing in a Hash/Assoc array, following by a SELECT
DK>>> query with a single column.


DK>>> @Dave,


DK>>> Could you share your inputs on this please.


--
Best regards,
 Vadim

Hello Dinesh,

Thursday, December 5, 2013, 1:38:10 PM, you wrote:


DK> I have reviewed your patch and managed to traverse each line
DK> of your code, except "AutoColumn" function body. Could you give me
DK> some information, when the pgAdmin goes to this function call.

You mean AutoSizeColumn()? In fact it is used only in
ctlSQLGrid::OnLabelDoubleClick(). If user doubleclicks column label
holding Ctrl/Meta, the column's manual size is forgotten and this
function is called to resize that single column immediately (otherwise
the user wouldn't notice the effect until re-execution of query).


DK> I have verified it in Mac/Linux/Windows, seems working fine. :)

Good news, thank you!

--
Best regards,
 Vadim

Hi

On Mon, Dec 9, 2013 at 8:58 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi,
>
> On Thu, Dec 5, 2013 at 8:42 PM, J.F. Oster <jinfroster@mail.ru> wrote:
>>
>> Hello Dinesh,
>>
>> Thursday, December 5, 2013, 1:38:10 PM, you wrote:
>>
>>
>> DK> I have reviewed your patch and managed to traverse each line
>> DK> of your code, except "AutoColumn" function body. Could you give me
>> DK> some information, when the pgAdmin goes to this function call.
>>
>> You mean AutoSizeColumn()? In fact it is used only in
>> ctlSQLGrid::OnLabelDoubleClick(). If user doubleclicks column label
>> holding Ctrl/Meta, the column's manual size is forgotten and this
>> function is called to resize that single column immediately (otherwise
>> the user wouldn't notice the effect until re-execution of query).
>
>
> OK. Thank you.
>
> @Dave:
>
> It seems good to me. I might be wrong in some places in analyzing this
> patch, hence requesting you to look into this once.

I took a look at this, and my only real concern is that the
auto-sizing code is forcing the grid to fully populate itself, which
it's currently specifically designed not to. The result of this is
that if you have a large dataset, there is a delay between when the
query finishes and the results are rendered.

I would suggest that instead of looking at the first 50 rows, and then
looking at every 500th row until the end, we just look at the first
500 and then stop. That won't be perfect of course, but it should
eliminate any delay with large amounts of data.


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

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

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.


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.


--
Best regards,
 J.F.

Hi

On Sun, Dec 15, 2013 at 6:26 AM, J.F. Oster <jinfroster@mail.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