Re: PATCH: Choose best width for Data Output columns of Query tool
От | Dave Page |
---|---|
Тема | Re: PATCH: Choose best width for Data Output columns of Query tool |
Дата | |
Msg-id | CA+OCxoxvTJ0CJgoHwUFtui+V+_rE-v3utE-2sudyAFV4fAUEQQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: Choose best width for Data Output columns of Query tool (Dinesh Kumar <dinesh.kumar@enterprisedb.com>) |
Список | 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
В списке pgadmin-hackers по дате отправления:
Следующее
От: "J.F. Oster"Дата:
Сообщение: Re: PATCH: Choose best width for Data Output columns of Query tool