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
--
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
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
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
> 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
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
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
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
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?
"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
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
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
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
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
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
---
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
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
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
18 matches
Mail list logo