4 ms·

Thanks a lot for your feedback. I truly appreciate it. Nothing can beat psql in speed in my opinion. pgXplorer carries the overhead of a GUI of course and ther

Thanks a lot for your feedback. I truly appreciate it. Nothing can beat psql in speed in my opinion. pgXplorer carries the overhead of a GUI of course and there is an added level of abstraction when talking to the database. pgXplorer has been built with ease-of-use in mind. > ..you're asking for "Port" twice... Sorry about it. It has been rectified at the source. I shall be updating the installers shortly. > what's the proposition? Why use pgXplorer instead of pgAdmin, for example? Good question. I started with the premise to supplant pgAdmin as the open source GUI tool for postgres. But I don't hold that view anymore. I am thinking of pgXplorer as another open source GUI for postgres. There are several design choices that are different from pgAdmin (and possibly other database GUI tools). * First of all, we have one instance of pgXplorer handling only one database at a time. So in the unpalatable event that pgXplorer crashes, it brings down only that instance. While one could launch multiple pgAdmins as well, it lists all connections regardless. * A 2-D grid like layout for tables,views and function on the main canvas with search option to quickly highlight a desired item. Very useful when dealing with names in Unicode, where there can be no perceptible alphabetical order (like Japanese). * The SQL editor/console is fully Unicode ready. In pgAdmin, when doing a search/replace with Unicode characters, pgAdmin's editor does not work well. * Editing tables and inserting data in tables handled in a better way than pgAdmin I think. Bulk updates can be done in pgXplorer when a single column is selected. * Copying and pasting data into LibreOffice Calc/Excel with headers. Also, it is quicker than pgAdmin. * A simple table designer for newly created (columnless) tables. These are some salient features of pgXplorer. More features are on the anvil.

bartonfink 14y ago
I'll make it a point to keep giving it a whirl, if only to help out a fellow HN'er. I do agree that there's room for improvement in the desktop DB client world, but I've not run into the problems with e.g. Unicode, that you mentioned. This is probably just my personal use history (I work for Mapquest and spend a large amount of time doing geographic queries). As I said, I'll continue giving it a whirl as best as I can. One thing that I have found virtually intolerable in any DB GUI client I've used is the latency after connection, presumably to load table definitions and other data for display. With psql, I connect and I just start going - the latency is imperceptible. I know that having such metadata readily visible is the reason people use GUI clients, but I find that I frequently don't need that. It's very easy for me to do a \d $tablename to see columns, or select count(1) from ... to get rowcounts as needed. In fact, the cost for doing this is roughly the same as the cost of clicking a table name to expand a schema in a GUI, so really all this sort of behavior does is get in my way. Another thing which I would find enticing would be special attention to displaying query plans. The output of "explain" isn't exactly the clearest, even to someone who's got a pretty good idea how a DB works, and I run explain queries infrequently enough that I have to check the documentation to make sure I'm understanding the result. Even simple clues - e.g. color coding the output so sequential scans are red, for instance - would help. Best of luck with it, though - and if I can help or if you want to bounce anything off me my e-mail is in my profile.
- davyjones 14y ago
  > latency after connection, presumably to load table definitions and other data for display You are correct. Particularly to have auto-completion on table names in the SQL editor, highlighting primary key columns, etc. (1) I understand that psql can be quicker in experienced hands. For me, particularly having to type out chinese characters for table names (I am not a native speaker of the language) is really difficult. pgXplorer eases some of that pain by auto-completing. So, in this specific case of mine, it is a bit quicker. > Another thing which I would find enticing would be special attention to displaying query plans. I presume you know about http://explain.depesz.com/ http://explain.depesz.com/? Very useful and open source too. I will be trying to add something similar in pgXplorer as well. Thanks a lot for the helpful offer. I will certainly connect by email to discuss some related things to the project. Edits: (1)

bartonfink 14y ago

I'll make it a point to keep giving it a whirl, if only to help out a fellow HN'er. I do agree that there's room for improvement in the desktop DB client world, but I've not run into the problems with e.g. Unicode, that you mentioned. This is probably just my personal use history (I work for Mapquest and spend a large amount of time doing geographic queries). As I said, I'll continue giving it a whirl as best as I can. One thing that I have found virtually intolerable in any DB GUI client I've used is the latency after connection, presumably to load table definitions and other data for display. With psql, I connect and I just start going - the latency is imperceptible. I know that having such metadata readily visible is the reason people use GUI clients, but I find that I frequently don't need that. It's very easy for me to do a \d $tablename to see columns, or select count(1) from ... to get rowcounts as needed. In fact, the cost for doing this is roughly the same as the cost of clicking a table name to expand a schema in a GUI, so really all this sort of behavior does is get in my way. Another thing which I would find enticing would be special attention to displaying query plans. The output of "explain" isn't exactly the clearest, even to someone who's got a pretty good idea how a DB works, and I run explain queries infrequently enough that I have to check the documentation to make sure I'm understanding the result. Even simple clues - e.g. color coding the output so sequential scans are red, for instance - would help. Best of luck with it, though - and if I can help or if you want to bounce anything off me my e-mail is in my profile.

davyjones 14y ago
> latency after connection, presumably to load table definitions and other data for display You are correct. Particularly to have auto-completion on table names in the SQL editor, highlighting primary key columns, etc. (1) I understand that psql can be quicker in experienced hands. For me, particularly having to type out chinese characters for table names (I am not a native speaker of the language) is really difficult. pgXplorer eases some of that pain by auto-completing. So, in this specific case of mine, it is a bit quicker. > Another thing which I would find enticing would be special attention to displaying query plans. I presume you know about http://explain.depesz.com/ http://explain.depesz.com/? Very useful and open source too. I will be trying to add something similar in pgXplorer as well. Thanks a lot for the helpful offer. I will certainly connect by email to discuss some related things to the project. Edits: (1)