Re: Lightspeed for frmQuery and other issues.
От | Andreas Pflug |
---|---|
Тема | Re: Lightspeed for frmQuery and other issues. |
Дата | |
Msg-id | 4454E95D.1010906@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: Lightspeed for frmQuery and other issues. ("Edward Di Geronimo Jr." <edigeronimo@xtracards.com>) |
Список | pgadmin-hackers |
Edward Di Geronimo Jr. wrote: > Quoting Andreas Pflug <pgadmin@pse-consulting.de>: > >> I still don't see a need for that extended handling, because the ctl >> always allowed row selections (and column selections can be achieved >> from SELECT ...., a basic SQL feature... ) > > > Very often in my work, I would not know exactly what columns I need the > data from until after I see the results of the query. Someone would > walk into my office and say "What's wrong with Joe Smith's account?" > I'd run a query to get an overview of the account, and what columns I > needed would change depending on what looked to be wrong. It's a lot > easier to click on the cell I need and hit copy than to run another > query to narrowing things down. > >>> Users dont care about virtual controls or not. >> >> >> They do. It's the speed issue, esp. on non-win32. > > > The implementation I did was 4x faster than the old implementation, > which apparently had been acceptable for a long time, but also offered > more features. There was no tradeoff to that work, unless you had a > phobia of grids. Yes I do have a wxGrid phobia. Making the frmEditGrid 80 % solution to 90 % was painful enough, and things tend to not get easier on the last 10 %. If you like fixing it in frmEditGrid, fine. The main speed issue was on gtk, and my small 1k row testcase did *not* show improvement. The current solution is ok for 10^n rows, as long as libpq and the OS can handle it. All previous versions, including yours, simply stalled. Regards, Andreas
В списке pgadmin-hackers по дате отправления: