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+OCxowRSojq+hoC+p12YCYjBPEJSCei9mAHfh8jgDSZ3J2okA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: Choose best width for Data Output columns of Query tool (Dinesh Kumar <dinesh.kumar@enterprisedb.com>) |
Ответы |
Re: PATCH: Choose best width for Data Output columns of Query tool
|
Список | pgadmin-hackers |
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
В списке pgadmin-hackers по дате отправления: