Обсуждение: Problem editing tables (geom columns)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, ok, 1st things 1st... System: Fedora 7 Kernel 2.6.21-1.3194.fc7 wxGTK 2.8.4 (compiled from source) Proj4 4.5.0 (compiled from source) Geos 3.0.0rc4 (compiled from source) PostGIS 1.2.1(compiled from source) Steps: First installed pgadmin3 1.6.3 from rpm Problems: - -Freezing while editing tables with geom fields - - If, per chance, it finally opens the table (after a long time) scrolling through the records freezes instantly. - - Processor time given for the pgadmin process (as seen with ps aux) rises up to 90%+ ! Downgraded to 1.6.2 - - Same problem - - downloaded pgadmin3-src-20070617.tar.gz from http://developer.pgadmin.org/snapshots/src/ compiled it with no errors - - Same problem I've seen in the known issues for ver 1.6.3 that there's a problem with editing tables with long fields... Strangely enough I've used this version before with Fedora Core 6 and there wasn't a problem with postgis tables.... :$ A long work has already been done setting up Fedora 7 to my taste so I'm really not too keen on downgrading to FC6... :-( So, I'm a bit lost here... Is this a GTK issue? What can I do to fix this? Kind regards, Pedro Doria Meunier -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iD8DBQFGdYvL2FH5GXCfxAsRAmb1AJ92i3qY4dDg4yIANMilxMS4ARpjoACfdUMf RgnJ/UIN0aY9pam0RIA48OE= =XQb6 -----END PGP SIGNATURE-----
Pedro Doria Meunier wrote: > I've seen in the known issues for ver 1.6.3 that there's a problem > with editing tables with long fields... Where do you see that? > Strangely enough I've used this version before with Fedora Core 6 and > there wasn't a problem with postgis tables.... :$ > A long work has already been done setting up Fedora 7 to my taste so > I'm really not too keen on downgrading to FC6... :-( > > So, I'm a bit lost here... Is this a GTK issue? > What can I do to fix this? Can you supply me a sample table and data to test with please? Thanks, Dave
Dave Page wrote: > Pedro Doria Meunier wrote: >> I've seen in the known issues for ver 1.6.3 that there's a problem >> with editing tables with long fields... > > Where do you see that? > >> Strangely enough I've used this version before with Fedora Core 6 and >> there wasn't a problem with postgis tables.... :$ >> A long work has already been done setting up Fedora 7 to my taste so >> I'm really not too keen on downgrading to FC6... :-( >> >> So, I'm a bit lost here... Is this a GTK issue? >> What can I do to fix this? > > Can you supply me a sample table and data to test with please? I've been playing with the data that Pedro supplied me offlist, and the problem is basically that he has a geometry value (basically a string) in a column of around 4MB. I think it's fairly safe to say that we'd be lucky to find that any of the grid controls on any of the platforms we support were happy with this amount of data in a single cell - in testing on Windows for example, whilst it works, it does slow to a crawl. I think the only sensible option would be to add an additional tab to the sort/filter dialog to allow the data to be vertically partitioned to exclude such columns. This isn't going to happen for the next release though I'm afraid. Thoughts? Regards, Dave.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (First of all sorry for cross-posting but I feel this is a matter that interests all recipients) Thread on pgadmin support: http://www.pgadmin.org/archives/pgadmin-support/2007-06/msg00046.php Hello Dave, This behavior (trying to show the entire geometry field) in Fedora Core 6, pgAdmin3 1.6.2, doesn't happen... In that scenario the geom field is simply shown blank. Nevertheless, if I recall it correctly, proj4, geos, postgis versions, in the above scenario, were older than the ones I'm using... So I wonder... could it be that pgadmin's code changed for showing large fields? Could one of proj4, geos, postgis code changed that really interferes with pgadmin3? IMHO, regardless of the scenario involved, the output for large geom fields should be suppressed in table edition... (as seen in the past) The current behavior hogs way too much processor time. <Dave> I've tested with a micro-subset of my data (only one record with a small parish geometry) and it shows although the slowness is immediately apparent... </Dave> Kind regards, Pedro Doria Meunier Dave Page wrote: > Dave Page wrote: >> Pedro Doria Meunier wrote: >>> I've seen in the known issues for ver 1.6.3 that there's a >>> problem with editing tables with long fields... >> Where do you see that? >> >>> Strangely enough I've used this version before with Fedora Core >>> 6 and there wasn't a problem with postgis tables.... :$ A long >>> work has already been done setting up Fedora 7 to my taste so >>> I'm really not too keen on downgrading to FC6... :-( >>> >>> So, I'm a bit lost here... Is this a GTK issue? What can I do >>> to fix this? >> Can you supply me a sample table and data to test with please? > > I've been playing with the data that Pedro supplied me offlist, and > the problem is basically that he has a geometry value (basically a > string) in a column of around 4MB. I think it's fairly safe to say > that we'd be lucky to find that any of the grid controls on any of > the platforms we support were happy with this amount of data in a > single cell - in testing on Windows for example, whilst it works, > it does slow to a crawl. > > I think the only sensible option would be to add an additional tab > to the sort/filter dialog to allow the data to be vertically > partitioned to exclude such columns. This isn't going to happen for > the next release though I'm afraid. > > Thoughts? > > Regards, Dave. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iD8DBQFGeWFf2FH5GXCfxAsRArySAKCeVIK5uzDEs+Q6ZS0A2Jye6c5h0ACeKlkf MqNA+rBORwi5Ko2x/rRV+Cc= =rOET -----END PGP SIGNATURE-----
Pedro Doria Meunier wrote: > (First of all sorry for cross-posting but I feel this is a matter that > interests all recipients) > Thread on pgadmin support: > http://www.pgadmin.org/archives/pgadmin-support/2007-06/msg00046.php > > Hello Dave, Hi Pedro > This behavior (trying to show the entire geometry field) in Fedora > Core 6, pgAdmin3 1.6.2, doesn't happen... > In that scenario the geom field is simply shown blank. There have been no changes in pgAdmin between 1.6.2 and 1.6.3 that might account for this behavioural change afaict. I imagine it's probably some difference in the platform's grid control between the two Fedora versions. > Nevertheless, if I recall it correctly, proj4, geos, postgis versions, > in the above scenario, were older than the ones I'm using... > So I wonder... could it be that pgadmin's code changed for showing > large fields? > Could one of proj4, geos, postgis code changed that really interferes > with pgadmin3? Unlikely. The data is essentially just text, and pgAdmin treats it as such. > IMHO, regardless of the scenario involved, the output for large geom > fields should be suppressed in table edition... (as seen in the past) > The current behavior hogs way too much processor time. Well, the suppression you saw wasn't us - I would guess it was simply that the grid control on the older Fedora just ignores the longer data. The problem we have trying to suppress it ourselves is that we'd either need to do it on a per row basis (because we only actually look at the data when a row is rendered on screen), or pre-scan all the data in every column before displaying it and make a decision on whether or not we should suppress entire column. The problem with the first idea is that it would be very confusing for the user - we might have some rows that we suppress and thus aren't editable, and others that we don't and therefore can be edited. The second method returns us back towards the <= v1.4 behaviour where we had query runtime + display time in the query tool. It would significantly slow things down :-( What I'm currently thinking is just that we add a tab to the Filter/Sort dialog to allow non-primary key columns to be switched on or off, so you can disable the larger columns before the query is even run. We can make that more convenient by saving those options (as well as the sort/filter options) on a per-table basis. I'd like some more thoughts from some of the other pgAdmin devs before we settle on that though. Regards, Dave