Re: [pgadmin-support] Very slow viewing of large table.
> -Original Message- > From: Constantin Stefanov [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 07:30 > To: [EMAIL PROTECTED] > Subject: Re: [pgadmin-support] Very slow viewing of large table. > > Thanks, I set that value to 0, and now I have the desired behaviour. > But, for that table the values are: > Rows(estimated) - 7 > Rows(counted) - 77204608 > I think the difference is too large. From the debug output I > could not understand the query which pg_admin issues to have > the value for estimated number of rows. Could you show me > that query so I could give it directly from psql to see > whether there is an error in my database stats or there is a > bug in pg_admin when interpreting query result? It works fine for me, so the query is probably right. When did you last run VACUUM ANALYZE on that table or database? The value comes from pg_class.reltuples which is updated by VACUUM ANALYZE: SELECT relname, reltuples FROM pg_class; Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-support] Very slow viewing of large table.
Dave Page wrote: Thanks, I set that value to 0, and now I have the desired behaviour. But, for that table the values are: Rows(estimated) - 7 Rows(counted) - 77204608 I think the difference is too large. From the debug output I could not understand the query which pg_admin issues to have the value for estimated number of rows. Could you show me that query so I could give it directly from psql to see whether there is an error in my database stats or there is a bug in pg_admin when interpreting query result? It works fine for me, so the query is probably right. When did you last run VACUUM ANALYZE on that table or database? I have VACCUM ANALYZE every nignt and VACCUM FULL every week. The value comes from pg_class.reltuples which is updated by VACUUM ANALYZE: SELECT relname, reltuples FROM pg_class; For my table there is -- accounting# SELECT relname, reltuples FROM pg_class where relname='ip_accounting'; relname| reltuples ---+- ip_accounting | 7.71493e+07 -- May be there is some overflow or incorrect result parsing? -- Constantin Stefanov ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] Very slow viewing of large table.
> -Original Message- > From: Constantin Stefanov [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 08:59 > To: [EMAIL PROTECTED] > Subject: Re: [pgadmin-support] Very slow viewing of large table. > > > SELECT relname, reltuples FROM pg_class; > For my table there is > -- > accounting# SELECT relname, reltuples FROM pg_class where > relname='ip_accounting'; > relname| reltuples > ---+- > ip_accounting | 7.71493e+07 > -- > May be there is some overflow or incorrect result parsing? Hmm, shouldn't be - the code appears to use longs everywhere. I can't really spend time on this now though - Andreas, can you take a look please? Thanks, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-support] Very slow viewing of large table.
Dave Page wrote: -Original Message- From: Constantin Stefanov [mailto:[EMAIL PROTECTED] Sent: 23 October 2003 08:59 To: [EMAIL PROTECTED] Subject: Re: [pgadmin-support] Very slow viewing of large table. SELECT relname, reltuples FROM pg_class; For my table there is -- accounting# SELECT relname, reltuples FROM pg_class where relname='ip_accounting'; relname| reltuples ---+- ip_accounting | 7.71493e+07 -- May be there is some overflow or incorrect result parsing? Hmm, shouldn't be - the code appears to use longs everywhere. I can't really spend time on this now though - Andreas, can you take a look please? It's not an overflow, instead the column is scanned as int, resulting in reltuples=7 (which isn't too precise :-) I changed the types of rows to wxLongLong, and estimatedRows to double now. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] German umlauts in pgadmin III
Albin Blaschka wrote: Hello, Thanks for all the answers, I solved the problem with "converting" my databases to Latin1... (dumping the data, dropping the DB, recreate it with Latin1, reloading data) Was quite an effort, but did it and without problems... BTW: PGAdmin III, V1.01 did *not* work in that case (displaying german umlaute properly...) Thanks, Albin -- ** Albin Blaschka, Mag. rer. nat. ** BAL Gumpenstein ** Projekt: Landschaft und Landwirtschaft im Wandel ** Tel.: 03682 / 22451 - 244 ** No trees were killed in the creation of this message. ** However, many electrons were terrible inconvenienced. -- Von:Dave Page[SMTP:[EMAIL PROTECTED] Gesendet: Mittwoch, 22. Oktober 2003 13:28 An: Andreas Pflug; Albin Blaschka Cc: [EMAIL PROTECTED]; Reinhard Resch; Wilhelm Graiss Betreff:RE: [pgadmin-support] German umlauts in pgadmin III -Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 20 October 2003 10:07 To: Albin Blaschka Cc: '[EMAIL PROTECTED]'; Reinhard Resch; Wilhelm Graiss Subject: Re: [pgadmin-support] German umlauts in pgadmin III Umlaute are no ascii chars, so they can't converted to unicode. V1.0.1 which was released some days ago has a workaround for miscoded databases, leaving encoding conversions to the client if the db is created SQL_ASCII. I just ran into this on my system with the £ symbol (UK Pound symbol, not #), however the fix doesn't seem to work in CVS tip - Any column that contains a £ value anywhere in it shows up as having a null value. At very least I would expect to see an 'unknown char' symbol in place of the pound sign, and the rest of the string intact. Regards, Dave. While the conversion *is* correctly determined for each connection, it wasn't applied in pgSet... Done now (head and trunk). Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgadmin-support] Execute TO in PgadminIII
Tino Wildenhain wrote: Very sexy would be this: http://www.python.org/doc/current/ext/embedding.html So we would be able to develop a zillon of plugins for every platform - just as a script hook for pgAdmin :-) Yes, Python *is* sexy, it's my first choice. We certainly shouldn't reinvent the wheel developing another kind of snapin technology. There's a wxPython too, maybe this could help us integrating the python scripting engine. BTW this is certainly a hackers topic, let's keep this list dedicated to user's problem with existing features. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-support] Very slow viewing of large table.
> -Original Message- > From: Andreas Pflug [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 11:51 > To: Dave Page > Cc: Constantin Stefanov; [EMAIL PROTECTED] > Subject: Re: [pgadmin-support] Very slow viewing of large table. > > Dave Page wrote: > > > > > > > > > > >>-Original Message- > >>From: Constantin Stefanov [mailto:[EMAIL PROTECTED] > >>Sent: 23 October 2003 08:59 > >>To: [EMAIL PROTECTED] > >>Subject: Re: [pgadmin-support] Very slow viewing of large table. > >> > >> > >> > >>>SELECT relname, reltuples FROM pg_class; > >>> > >>> > >>For my table there is > >>-- > >>accounting# SELECT relname, reltuples FROM pg_class where > >>relname='ip_accounting'; > >> relname| reltuples > >>---+- > >> ip_accounting | 7.71493e+07 > >>-- > >>May be there is some overflow or incorrect result parsing? > >> > >> > > > >Hmm, shouldn't be - the code appears to use longs > everywhere. I can't > >really spend time on this now though - Andreas, can you take a look > >please? > > > > > It's not an overflow, instead the column is scanned as int, > resulting in > reltuples=7 (which isn't too precise :-) I changed the types > of rows to wxLongLong, and estimatedRows to double now. Of course (kicking myself now...) Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-support] EXPORT from Query Tool
was: Execute TO in PgadminIII Tino Wildenhain wrote: Re: [pgadmin-support] EXPORT from Query Tool (was: Execute TO in PgadminIII) But simple HTML would do the trick for Excel and even OpenOffice can read this: column1column2 ... and so on. We can have multiple export formats, of course. Currently, we have the wide-spread CSV format, with (hopefully) all needed options. We may have a discussion about more export formats on pgadmin-hackers. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
