[BUGS] Rapid deteriation of performance (might be caused by tsearch?) in 7.3.2
Up until a few days ago I have been running Postgresl 7.2.3 with Tsearch from the contrib dir, but at various times the performance of the database would suddenly and rapidly deteriate so that queries which previously took 500ms then took 8 or 9 seconds. The only cure is a backup and restore of the database, vacuuming and analysing does nothing. I even tried rebuilding all indexes once which didn't seem to help. This was an annoying but intermittent thing, which happened the last time this Wednesday. Since I was doing a backup and restore anyway, I decided to upgrade to 7.3.2 in the hope this might fix the annoying problem, however it has made it WAY worse. Rather than going a few weeks (and sometimes months) in between having to use this fix, I am now having to do it almost every single day. I'm now lucky if it lasts 24 hours before it brings my website to a total crawl. There is nothing special about my database other than the fact that I use the Tsearch addon. Now if I go and do a bit update to the Tsearch indexes on a table, with for example: UPDATE tblmessages SET strmessageidx=txt2txtidx(strheading || ' ' || strmessage); Then that instantly brings the whole database to a crawl, which no amount of index rebuilding, vacuuming and analysing helps. Help! (And sorry if this is the wrong list) Yours Unwhettedly, Robert John Shepherd. Editor DVD REVIEWER The UK's BIGGEST Online DVD Magazine http://www.dvd.reviewer.co.uk For a copy of my Public PGP key, email: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] index problem when renaming a table
Hi , I used the command: ALTER TABLE TEST_TABLE RENAME TO TEST_TABLE_01; and tried to create a new one, based on the old, with some more fields. But when I create the primary key, it says that it's name is already used and it can't be dome, and exits. Then I have to drop the old table's index, recreate it and create the new table again. Isn't it a bug? Why can't I have the same name in 2 or more tables in the same database? Or why PostgreSQL don't create a PK with some random name (say PK_TBL01_1234) to each table so the index name won't be duplicated? TIA, Ricardo. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Rapid deteriation of performance (might be caused by tsearch?) in 7.3.2
"Robert John Shepherd" <[EMAIL PROTECTED]> writes: > Help! (And sorry if this is the wrong list) Yes, it's the wrong list. pgsql-performance would be the place to discuss this. We can't help you anyway without more details: show us the EXPLAIN ANALYZE results for some of the slow queries. (Ideally I'd like to see EXPLAIN ANALYZE for the same queries in both fast and slow states ...) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Psql 'Expanded display (\x)' behaviour
Hello! I'm new to this list and hope it is the right one (I posted to General and Novice but got no answer). I know that issues concerning the (erroneously) so called extended ASCII chars are of partial interest to English speaking people ... so I should be very grateful if any of you could confirm that: toggling on/off the 'Expanded display' (in psql) does affect the display of non-ascii chars. Regards, Ennio. --- PS: I'm using: Linux .. 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i586 unknown PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.95.4 $ /usr/lib/postgresql/bin/pg_controldata /var/lib/postgres/data [cut] LC_COLLATE: it_IT LC_CTYPE: it_IT but tried other charsets with the same result: accented letters display ok only when 'expanded display' is turned off (in which case, however, the pager doesn't work!). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Psql 'Expanded display (\x)' behaviour
Ennio-Sr writes: > toggling on/off the 'Expanded display' (in psql) does affect the display > of non-ascii chars. Not at all. It's only an alternative table format. > but tried other charsets with the same result: accented letters display > ok only when 'expanded display' is turned off (in which case, however, > the pager doesn't work!). Perhaps the problem is that the pager does not handle the accented characters right. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Bug #934: readline.h not found during configure
Bill Eichin ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description readline.h not found during configure Long Description I'm running debian woody, and I've been revisiting this problem for several months. I had no choice during compile except to select --without-readline in order to move on in the compile process. Just about twenty minutes ago, I found that installing the "libedit-dev" package provided me with the "/usr/include/libedit/libreadline.h file. Symlinking /usr/include/libedit to /usr/include/libreadline made the configure process succeed without disabling readline. I don't know exactly who to complain to, or what exactly to complain about. So, here it it, and if you want to check out the details, I'll get you a logon into the server I'm doing this on. Thanks, in advance, for having a bug reporting system :) Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #934: readline.h not found during configure
On Fri, 4 Apr 2003 [EMAIL PROTECTED] wrote: > Bill Eichin ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > readline.h not found during configure > > Long Description > I'm running debian woody, and I've been revisiting this problem for > several months. I had no choice during compile except to select > --without-readline in order to move on in the compile process. Just > about twenty minutes ago, I found that installing the "libedit-dev" > package provided me with the "/usr/include/libedit/libreadline.h file. > Symlinking /usr/include/libedit to /usr/include/libreadline made the > configure process succeed without disabling readline. Does --with-includes=/usr/include/libedit on configure line help at all (without the symlink that is)? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
