Re: R: R: [ADMIN] slow seqscan after vacuum analize

2004-02-05 Thread Sam Barnett-Cormack
On Thu, 5 Feb 2004, Edoardo Ceccarelli wrote: > after a VACUUM FULL ANALYZE (1h!!) things are ok Only a hour - lucky you ;) -- Sam Barnett-Cormack Software Developer | Student of Physics & Maths UK Mirror Service (http://www.mirror.ac.uk) | Lancaster University --

Re: [ADMIN] R: R: slow seqscan after vacuum analize

2004-02-05 Thread Christopher Browne
In the last exciting episode, [EMAIL PROTECTED] ("Edoardo Ceccarelli") wrote: > Yes, you are right but it wasn't the case this time, I have run the > explain plenty of times with same results. I think that the reason > was that I made a simple VACUUM, after a VACUUM FULL ANALYZE (1h!!) > things ar

Re: [ADMIN] R: slow seqscan after vacuum analize

2004-02-05 Thread Christopher Browne
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Iain") would write: > I'd like to know more about the possibility of plain vacuums harming > performance. This is the first I've heard of it. Vacuum full is not always > an option in a production environment. There certainly are known cas

Re: R: [ADMIN] slow seqscan after vacuum analize

2004-02-05 Thread Andrew Biagioni
Iain wrote: Yes, you are right but it wasn't the case this time, I have run the explain plenty of times with same results. I think that the reason was that I made a simple VACUUM, after a VACUUM FULL ANALYZE (1h!!) things are ok I

R: [ADMIN] R: slow seqscan after vacuum analize

2004-02-05 Thread Edoardo Ceccarelli
> But if the Original Poster is encountering that the database > is doing Seq Scans when it would be better to do an Index > Scan, that is a separate problem, and focusing on the VACUUM > may distract from the _real_ problem... > -- I have only noticed that after a VACUUM ANALYZE of the db the

Re: [ADMIN] R: R: slow seqscan after vacuum analize

2004-02-05 Thread Tom Lane
Christopher Browne <[EMAIL PROTECTED]> writes: > Another factor worth considering: If a few values are very common in > the field you are selecting on, then the query optimizer can get > convinced (wrongly) that a Seq Scan is the best choice. Using ALTER > TABLE T ALTER COLUMN C SET STATISTICS [so

[ADMIN] VACUUM Quesition

2004-02-05 Thread Stefan Sturm
Hello, I have a question about vaccum. There are thre Version of vaccums: 1.) plain vacuum 2.) vacuum analyze 3.) full vacuum Is it right that a vacuum analyze includes the plain vacuum and the full vacuum includes the vacuum analyze? And which vacuum locks the tables? And is there a strategy wh

Re: [ADMIN] VACUUM Quesition

2004-02-05 Thread Sam Barnett-Cormack
On Thu, 5 Feb 2004, Stefan Sturm wrote: > Hello, > > I have a question about vaccum. There are thre Version of vaccums: > 1.) plain vacuum > 2.) vacuum analyze > 3.) full vacuum > > Is it right that a vacuum analyze includes the plain vacuum and the full > vacuum includes the vacuum analyze? And w

[ADMIN] Installation procedure

2004-02-05 Thread Ivan Zenzerović
I have a problem. After i installed the apache2 web server i wanted to install pgsql. I run ./configure and after that i tried to run make but then it outputs an error which said to run configure first. What is the problem here?

Re: R: [ADMIN] R: slow seqscan after vacuum analize

2004-02-05 Thread Tom Lane
"Edoardo Ceccarelli" <[EMAIL PROTECTED]> writes: > Given a query that HAS to be executed with a seqscan I have noticed an > increase in time comparing before and after the vacuum. This is really hard to believe --- I cannot think of any mechanism that would result in that effect. Unless the vacuu

Re: [ADMIN] Installation procedure

2004-02-05 Thread Peter Eisentraut
Ivan Zenzerović wrote: > I have a problem. After i installed the apache2 web server i wanted > to install pgsql. I run ./configure and after that i tried to run > make but then it outputs an error which said to run configure first. Probably an error happened during the run of configure. If you nee

[ADMIN] pg-watchdog

2004-02-05 Thread Mark Harrison
Here is the final version of my script that will watch for disconnected client machines and kill their associated server side processes. If I'm doing anything really stupid I would appreciate hearing about it. If it's useful to anyone, feel free to pass it along. Thanks, Mark #!/bin/sh # the next l

Re: R: [ADMIN] R: slow seqscan after vacuum analize

2004-02-05 Thread Edoardo
On Thu, 05 Feb 2004 14:33:45 -0500, Tom Lane wrote > "Edoardo Ceccarelli" <[EMAIL PROTECTED]> writes: > > Given a query that HAS to be executed with a seqscan I have noticed an > > increase in time comparing before and after the vacuum. > > This is really hard to believe --- I cannot think of any

[ADMIN] Drop indexes inside transaction?

2004-02-05 Thread Steve Lane
Hello all: Question here about how best to optimize a large data load. Data load is ad hoc and so needs to be able to run during production hours. We have a piece of software written in a desktop RAD environment (FileMaker Pro). Our users are using this tool to generate data that we need to get i

[ADMIN] Index (re)-creation speed

2004-02-05 Thread Steve Lane
All: Been looking at speed issues related to loading large data sets, and experimenting with dropping and rebuilding indexes. I noticed some interesting behavior on the table in question. Here's the table: Table "test_responses_2" Attribute | Type| Modifier ---

Re: [ADMIN] Drop indexes inside transaction?

2004-02-05 Thread Tom Lane
Steve Lane <[EMAIL PROTECTED]> writes: > Now we want to use COPY to bring the data in. The target table has 6 > indexes. Without indexes, naturally, we can load 80K rows in 2 seconds. With > indexes, 46 seconds. (oddly, ONE index contributes 40+ seconds of that, yet > they're all similar, single-co

Re: [ADMIN] Index (re)-creation speed

2004-02-05 Thread Tom Lane
Steve Lane <[EMAIL PROTECTED]> writes: > When I drop and rebuild the indexes, they take oddly varying amounts of time > to rebuild. I rebuilt them in the following order, with the following rough > times. I took a guess that the speed of the rebuild might be related to the > number of distinct valu

Re: [ADMIN] Drop indexes inside transaction?

2004-02-05 Thread Steve Lane
On 2/6/04 12:23 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote: > Steve Lane <[EMAIL PROTECTED]> writes: >> Now we want to use COPY to bring the data in. The target table has 6 >> indexes. Without indexes, naturally, we can load 80K rows in 2 seconds. With >> indexes, 46 seconds. (oddly, ONE index contr