Re: [GENERAL] Problem after VACUUM ANALYZE

Hi all, dear Richard, your mail about my configuration parameter were the right hint, but i am still struggling with the problem. i will appreciate if you or somebody else can help me even further. After some investigation i got some new results to my problem. The following query is not workin

Re: [GENERAL] Problem after VACUUM ANALYZE

Am Mittwoch, 9. April 2008 10:11 schrieb David Wilson: > On Wed, Apr 9, 2008 at 3:29 AM, <[EMAIL PROTECTED]> wrote: > > But if i do "VACUUM ANALYZE" without concurrent queries, everything runs > > fine afterwards. > > > > If i run "VACUUM ANALYZE" with few concurrent queries, it slows down to >

Re: [GENERAL] Problem after VACUUM ANALYZE

Am Dienstag, 8. April 2008 18:38 schrieb Scott Marlowe: > It sounds to me like two possible problems, maybe combined. > > One possibility is that you have a data distribution that results in > statistics being gathered that don't really represent your data. Try > increasing the stats target for th

Re: [GENERAL] Problem after VACUUM ANALYZE

HI Richard, thanks for your immediate response. I will answer your questions below: Am Dienstag, 8. April 2008 17:40 schrieb Richard Huxton: > [EMAIL PROTECTED] wrote: > > We looked in our cpu monitoring and saw that we have huge IOwait while > > VACUUM is running, not unusual though. But just af

[GENERAL] Problem after VACUUM ANALYZE

Hi all, our postgresql DB was running fine for a long time, but suddenly we encountered a huge problem which we got fixed only temporarily. We are running debian stable with postgresql 8.1.11. Our app is connecting via JDBC and uses Prepared Statements. We are not running autovacuum but a nig

Re: [GENERAL] Very long execution time of "select nextval('..');"

Hi Greg, hi Tom, Am Sonntag, 27. Januar 2008 22:44 schrieb Tom Lane: > [EMAIL PROTECTED] writes: > > ok, at the moment i got some traffic and my load is at 1.5. But now with > > logging the timestamp I have seen that the long durations are quite > > regular at intervals of 10 minutes. > > Well, th

Re: [GENERAL] Very long execution time of "select nextval('..');"

Hi Greg, first fo all: thanks a lot. i think i understood most of your comments, but - of course - have now more questions than before :-) Am Montag, 28. Januar 2008 01:07 schrieb Greg Smith: > On Sun, 27 Jan 2008, [EMAIL PROTECTED] wrote: > > ok, at the moment i got some traffic and my load is

Re: [GENERAL] Very long execution time of "select nextval('..');"

Am Sonntag 27 Januar 2008 18:56:49 schrieb Tom Lane: > [EMAIL PROTECTED] writes: > > we run postgresql-8.1 on a dedicated debian box 64bit, dual-core CPU, 8GB > > RAM, RAID-1. > > 8.1.what? 8.1.11-0etch1 > > LOG: duration: 12636.746 ms statement: EXECUTE [PREPARE: > > select nextval ('member

[GENERAL] Very long execution time of "select nextval('..');"

Hi, we run postgresql-8.1 on a dedicated debian box 64bit, dual-core CPU, 8GB RAM, RAID-1. We select our primary keys with select nextval before we actually insert a record. In my logs i print every statement which takes longer than 250ms there are lots of values fetched each day with nextval

Re: [GENERAL] Prepared Statements

first: thanks a lot for your answer. it already helped me a lot, but i still have some questions: Am Mittwoch, 9. Januar 2008 21:16 schrieb Kris Jurka: > On Wed, 9 Jan 2008, [EMAIL PROTECTED] wrote: > > - I know there is a PREPARE Statement in Postgresql and read the docs. > > - in PostgresqlJDBC

[GENERAL] Prepared Statements

Hi, i am trying to understand "Prepared Statements". I am asking because i want to understand the impact of "Prepared statements" to my application. Actually i use Hibernate, DBCP Connection Pool with Postgresql-JDBC Driver and Postgresql 8.1. - I know there is a PREPARE Statement in Postgresq

[GENERAL] File system level backup from 32bit to 64bit

i wanted to move my database from a 32bit machine to 64bit machine with rsync like it is explained here http://www.postgresql.org/docs/8.1/interactive/backup-file.html I did an inital rsync while database was running. then shutdown, rsync again, starting 64bit database says: /var/lib/postgres

Re: [GENERAL] Memory on 32bit machine

Am Montag, 7. Januar 2008 12:56 schrieb Florian Weimer: > > Or would you rather vote for 64bit because there are no problems > > anymore and postgresql runs fine on 64bit debian. > > We haven't run into any trouble with iptables on Debian etch, running > on amd64 hardware. But we use only fairly s

Re: [GENERAL] Memory on 32bit machine

Am Montag, 7. Januar 2008 11:48 schrieb Martijn van Oosterhout: > On Mon, Jan 07, 2008 at 10:32:26AM +0100, [EMAIL PROTECTED] wrote: > > So assuming i could choose between 4 GB RAM and 8 GB RAM and 32bit debian > > and 64bit debian. Which option would you choose? > > Always go for more RAM, whether

[GENERAL] Memory on 32bit machine

Hi, i have the option to upgrade to a new dedicated database server with 8 GB Ram i want to run on debian linux 32bit because i had some trouble the last time i used 64bit with iptables which did not work (i guess it was a year ago...) 8GB are addressable as far as i know with a bigmem kernel.

Re: [GENERAL] server process (PID 27884) was terminated by signal 4 (SIGILL)

Am Freitag, 4. Januar 2008 10:03 schrieb Steve Atkins: > On Jan 4, 2008, at 12:44 AM, [EMAIL PROTECTED] wrote: > > I just want to ask if there is something else > > besideds > > hardware failure which could force a signall 4 (ILL)? > > Software bugs can on rare occasions (by overwriting return stac

Re: [GENERAL] Updating a production database schema from dev server

Hi, try using liquibase. http://www.liquibase.org/ . It works very well. kind regards, Janning Am Dienstag, 16. Oktober 2007 18:38 schrieb Stanislav Raskin: > Hello everybody, > > > > I am currently running two PostgreSQL servers on two different machines. > One of them I use for development and

[GENERAL] server process (PID 27884) was terminated by signal 4 (SIGILL)

Hi, i had a rather strange crash of my server (log file at the end of my mailling) and i was googling for Signal 4 and read http://en.wikipedia.org/wiki/SIGILL i am running on linux 2.6.18-5-686 and postgresql-8.1.9-0etch2. Most (all?) other processes on this machine got signal 4 at this time a

[GENERAL] Restoring only some data from a backup file

hi, i run a webapp where lots of accounts are managing something. I do a nightly backup of my database. Sometime some users want to have their account restored from a backup days, weeks or months ago. At the moment i use (multi-column) natural keys. So each and every table has at least a colum

Re: [GENERAL] pgpool2 vs sequoia

Thank you guys! But now i am clueless as before. please, enlighten me: i need about 200 concurrent db connections at peak time and - at the moment - i only have cheap hardware (2-4 GB Ram, Dual Opteron CPU, SATA Disks, RAID 1) My database has a size of 11 GigaByte, largest table has 100.000.000

Re: [GENERAL] pgpool2 vs sequoia

Am Donnerstag, 2. August 2007 22:37 schrieben Sie: > On Thu, Aug 02, 2007 at 11:58:40AM +0200, [EMAIL PROTECTED] wrote: > > Hi, > > > > i would like to use a statement replication for postgresql > > Why? i have read http://www.postgresql.org/docs/8.2/interactive/high-availability.html i want 4 sy

Re: [GENERAL] pgpool2 vs sequoia

Am Donnerstag, 2. August 2007 12:04 schrieb Andy Dale: > Hi, > > You might also want to check out HA-JDBC at http://ha-jdbc.sourceforge.net thanks for this suggestion, so i have three options to choose from: - pgpool2 - sequoia - ha-jdbc Can someone share his experience on these? kind regards j

[GENERAL] pgpool2 vs sequoia

Hi, i would like to use a statement replication for postgresql i have found the following solutions: - pgpool - pgpool2 - sequoia (jdbc, formerly known as c-jdbc) pgpool has only two nodes, so this is not an option. I will never change my underlying database, of course :-) So i dont have any

Re: [GENERAL] createing indexes on large tables and int8

On Tuesday 17 July 2007 17:47:01 Tom Lane wrote: > [EMAIL PROTECTED] writes: > > i think i got it fixed as i saw that i pushed my maintenance_work_mem too > > high. It was higher than physical ram :-( > > Ooops, that will definitely cause problems. yes it did! I ran it again. And now it takes 10 m

Re: [GENERAL] int8 vs int4

On Tuesday 17 July 2007 17:52:11 you wrote: > [EMAIL PROTECTED] wrote: > > I use int8 types in most PK or FK columns in a pg 8.1 database. > > > > Would int4 instead of int8 speed up creation of an index? > > Almost certainly, but by how much will depend on your hardware and size > of index. > > >

[GENERAL] int8 vs int4

I use int8 types in most PK or FK columns in a pg 8.1 database. Would int4 instead of int8 speed up creation of an index? int4 will reduze the size of the table, of course. Would this reduce size of index, too? By the same amount? How much speed up will i gain on queries? Postgresql Doc menti

Re: [GENERAL] createing indexes on large tables and int8

Am Montag, 16. Juli 2007 16:19 schrieben Sie: > Janning Vygen <[EMAIL PROTECTED]> writes: > > After this i create the index and it took 10 hours just for one index > > (primary key). I have 100.000.000 rows with one PK (int8), two integer > > data values, and two FK (int8) > > What PG version is th

[GENERAL] restore dump to 8.19

Hi i tried to restore a dump from version 8.1.8 to 8.1.9 and i had in one table a value "1.7383389519587511e-310" i got the following error message: pg_restore: ERROR: type "double precision" value out of range: underflow CONTEXT: COPY gesamtpunktecache, line 925001, column gc_gesamtsiege: "