Re: [pgadmin-support] Large tables, copy-and-paste, default sql
> -Original Message- > From: ow [mailto:[EMAIL PROTECTED] > Sent: 09 November 2003 15:06 > To: [EMAIL PROTECTED] > Subject: [pgadmin-support] Large tables, copy-and-paste, default sql > > pgAdmin III, v1.0.0, pgSql 7.4.rc1 > > Hi, > > Thanks for the great product, it really helps! > > There a couple of things that, I think, could be improved still: > > 1. Tree view that shows the list of tables: When I click on a > table that contains relatively large number of rows (20M+), > it takes pgAdmin a very, very long time to show the > respective CREATE clause for the table. It appears that > pgAdmin is forcing pgSql to count rows in the table, though I > may be wrong. Is there a way to avoid the delay? pgAdmin checks the estimated row count before actually counting rows. You can set the threshold that will prevent counting under Tools->Options. > 2. pgAdmin Query/Sql tool: It'd be nice if there was a way to > copy data from the "data output" tab. I know it can be > exported, but many times I need just a small piece of data > and it'd be nice to just copy-and-paste. You can copy individual values using the normal keysequences such as Control-C for copy. Currently you cannot select regions of cells for copy/paste - I'm not sure how feasible this is right now, though I can see the usefullness of it. > > 3. pgAdmin Query/Sql tool: IMHO, it be better if Sql/Query > tool window opened blank, i.e. without prepopulating it with > SQL of the item that had focus when Query tool was launched. > Most of the time (99%), I remove default SQL, it does not do > me any good. There is an option to prevent this under Tools->Options. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-support] Large tables, copy-and-paste, default sql
Dave Page wrote: 1. Tree view that shows the list of tables: When I click on a table that contains relatively large number of rows (20M+), it takes pgAdmin a very, very long time to show the respective CREATE clause for the table. It appears that pgAdmin is forcing pgSql to count rows in the table, though I may be wrong. Is there a way to avoid the delay? pgAdmin checks the estimated row count before actually counting rows. You can set the threshold that will prevent counting under Tools->Options. Please note that there is a float interpretation problem in 1.0.0 (7.6e6 -> 7 instead of 700), which leads to wrong table size estimated values (and thus wrong thresholds for automatic row counting). Regards, Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-support] RE
Reshat Sabiq wrote: Mark Perez wrote: Can someone help me? I have a large database that I have been working on in MS Access and then placed it on a Red Hat Server. It works awesome with PGAdmin and PostgreSQL. I then needed to take the code and database both an Access based import and a pgdump. When I installed the beta version, I restored the dump and all the tables appeard and they were empty. All the data was gone. So, I then imported the tables one by one, having a total of 275 tables. After importing using the Wizard, I then tried to perform SQL's, however, I had NO data listed in any of the Sequels, unless I did a SELECT * FROM [table_name], etc. All the data was there with that. But for complex issues such as CASE WHEN's and =, +, >, <, etc. No data would result from them and was told that I would have to name "explicit typecasts. I am trying to find out why, but most importantly, HOW I can proceed. I, then, went one step forward and purchased the box set of Red Hat 7.1 and after installation of the Operat ing System, I still cannot get it to work. Unfortunatey, Linux is so cumbersome that I just gave up. Is there anyone out there who knows how I can get around this? Becasue, I am now returning my Linux and reinstalling my Windows 2000 Server, which I should have never given up in the first place. I LOVE PostgreSQL and the performance is exceptional and this I do not want to change, but just wish that it was more of a Windows based Database Server, rather than Linux. Thank you all and if there is any advise you can give me, please do. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html Could that be an encoding issue? No, this is a plain PostgreSQL SQL issue. Depending on the column types, you have to typecast explicitely, as the message suggests. This is *not* the list for generic SQL questions, use pgsql-sql instead. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] More on connetions to SSL enabled servers
[EMAIL PROTECTED] wrote: I just installed Fedora Core 1 from fedora.redhat.com. I decided to build pgadmin3 from source. I installed the wx rpms for Redhat 9 and installed the postgresql rpms for Fedora Core 1. I was able to build and install pgadmin3 successfully. I then connected to my SSL enabled PostgreSQL 7.3 server. The Query Tool doesn't cause everything to crash but the query never stops running. When I click on the Stop button in the Query Tool pgadmin3 quits responding but doesn't outright crash. I did try building pgadmin3 from source on a RedHat9 machine and I remember having the same issues. Tim Can you play around with compile/link options and libraries (multithread enabling)? Could you try using libpq 7.4? Jean-Michel, did you play around with ssl on your machines already? Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-support] Large tables, copy-and-paste, default sql
--- Dave Page wrote: > [...] > > You can copy individual values using the normal keysequences such as > Control-C for copy. Currently you cannot select regions of cells for > copy/paste - I'm not sure how feasible this is right now, though I can > see the usefullness of it. That I couldn't do, i.e. it appears that the least I can select in the "data output" tab is the whole row (can't select a column or a single cell) and copy-and-paste does not appear to work on rows. Suspending table counts and default SQL as per File->Options worked fine. Thanks! __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[pgadmin-support] OS X?
Well, well… Some weeks have passed by since the release of Panther, but nowhere have I been able to find the so long awaited port for Mac OS X… Does anyone here have some updated information about the status of the OS X-project? Sincerely, Victor, Copenhagen/Malmoe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[pgadmin-support] Bug
pgAdmin III, v1.0.0, pgSql 7.3.1 Windows Russian Hello! PostrgeSQL on windows make SuperUser's name symbols as current system user. When user in windows include russian, PgSQL make user with russian symbols too. But pgAmin replace it to "_". For Example: My user was "Dmitriy" (Дмитрий). There is PgSQL error: 'Uncknown user "___"'. I know, that russian usernames it's bad, but differnt other pgSQL manager's (like EMS PostrgeSQL manager) work with russian names correct. P.S. Sorry for my English - i'm from Russia and speak English very bad. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] Bug
Дмитрий Попов wrote: pgAdmin III, v1.0.0, pgSql 7.3.1 Windows Russian Hello! PostrgeSQL on windows make SuperUser's name symbols as current system user. When user in windows include russian, PgSQL make user with russian symbols too. But pgAmin replace it to "_". For Example: My user was "Dmitriy" (Дмитрий). There is PgSQL error: 'Uncknown user "___"'. I know, that russian usernames it's bad, but differnt other pgSQL manager's (like EMS PostrgeSQL manager) work with russian names correct. Hi Dmitriy, actually I didn't understand exactly what the problem is, so I'm guessing that you got a conversion problem. Do you have SQL_ASCII as database encoding? If yes, this is a problem, because Russian characters are not ascii. There are two options: 1) (the better option) use UNICODE or the Russian encoding in the database. 2) Use a newer pgAdmin3 version, we have a new workaround for SQL_ASCII databases with wrong characters. Regards, Andreas P.S. Sorry for my English - i'm from Russia and speak English very bad. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-support] Bug
Dear Дмитрий Попов . I believe the reappearance of this problem. IMHO,You must not use multi-byte for the user ID. It seems you that it that a user was made under the condition of the multi-byte connection is right by the intervention of conversion. However, The user character line won't correspond so far as conversion is never minded at the time of the connection connection. regards, Hiroshi Saito - Original Message - From: "Andreas Pflug" <[EMAIL PROTECTED]> To: "Дмитрий Попов" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, November 11, 2003 8:55 AM Subject: Re: [pgadmin-support] Bug > Дмитрий Попов wrote: > > >pgAdmin III, v1.0.0, pgSql 7.3.1 Windows Russian > > > >Hello! > > > >PostrgeSQL on windows make SuperUser's name symbols as current system > >user. When user in windows include russian, PgSQL make user with > >russian symbols too. > >But pgAmin replace it to "_". > > > > > >For Example: My user was "Dmitriy" (Дмитрий). There is PgSQL error: > >'Uncknown user "___"'. > > > >I know, that russian usernames it's bad, but differnt other pgSQL > >manager's (like EMS PostrgeSQL manager) work with russian names > >correct. > > > > > > > > > > > Hi Dmitriy, > > actually I didn't understand exactly what the problem is, so I'm > guessing that you got a conversion problem. Do you have SQL_ASCII as > database encoding? If yes, this is a problem, because Russian characters > are not ascii. > There are two options: > > 1) (the better option) > use UNICODE or the Russian encoding in the database. > > 2) Use a newer pgAdmin3 version, we have a new workaround for SQL_ASCII > databases with wrong characters. > > Regards, > Andreas > > >P.S. Sorry for my English - i'm from Russia and speak English very > >bad. > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
