Richard Huxton wrote:
Ruben Rubio Rey wrote:
Hi,
I think im specting problems with a 7.4.8 postgres database.
Sometimes some big query takes between 5 to 15 seconds. It happens
sometimes all the day it does not depend if database is busy.
I have measured that sentence in 15 - 70 ms in
Information, Ruben - we can't do anything without information.
What usefull information could I provide?
Offending queries, EXPLAIN ANALYZE, tables description, condiguration
parameters, hardware, intended use...
---(end of broadcast)---
unsubscribe
---(end of broadcast)---
TIP 6: explain analyze is your friend
Craig A. James wrote:
If I only insert data into a table, never update or delete, then I should
never have to vacuum it. Is that correct?
You still need to vacuum eventually, to avoid transaction Id wraparound
issues. But not as often.
--
Alvaro Herrera
Alvaro Herrera wrote:
If I only insert data into a table, never update or delete, then I should
never have to vacuum it. Is that correct?
You still need to vacuum eventually, to avoid transaction Id wraparound
issues. But not as often.
Thanks. Any suggestions for what not as often means?
Craig A. James wrote:
Alvaro Herrera wrote:
If I only insert data into a table, never update or delete, then I should
never have to vacuum it. Is that correct?
You still need to vacuum eventually, to avoid transaction Id wraparound
issues. But not as often.
Thanks. Any suggestions
Hello,
Attached is the text file containing the last rounds of configurations.
This time, used show all just before issuing each relevant explain analyze
to ensure available information.
Note that the last runs are being executed concurrently with other problematic
query that is consuming 100% cpu
Andre,
http://candle.pha.pa.us/main/writings/pgsql/hw_performance/
brought some light over the subject. For few users, could be a viable
alternative.
That article is very old. Read this instead:
http://www.powerpostgresql.com/PerfList
select count(distinct NF.ID_NF ) as contagem,
Craig,
Transaction ID wraparound will be a problem at a bit less than 2 billion
transactions. So if you vacuum the table every 1 billion transactions
you are safe. I suggest you read the routine maintenance section in
the docs; the wraparound issue is explained there.
For reference, we
On Mon, 2006-03-13 at 12:11, andremachado wrote:
Hello,
Attached is the text file containing the last rounds of configurations.
This time, used show all just before issuing each relevant explain analyze
to ensure available information.
Note that the last runs are being executed concurrently
On Mon, Mar 13, 2006 at 09:19:32 -0800,
Craig A. James [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
If I only insert data into a table, never update or delete, then I should
never have to vacuum it. Is that correct?
You still need to vacuum eventually, to avoid transaction Id
On Mon, Mar 13, 2006 at 06:49:39PM -0500, mcelroy, tim wrote:
Does anyone know how much of a performance hit turning stats_block_level and
stats_row_level on will incur? Do both need to be on to gather cache
related statistics? I know the annotated_conf_80 document states to only
turn them
Hi all,
I'm trying to work out why my 8.1 system is slower than my 7.4 system
for importing data.
The import is a lot of insert into commands - it's a converted
database from another system so I can't change it to copy commands.
My uncommented config options:
autovacuum = off
On Tue, 14 Mar 2006, Chris wrote:
Hi all,
I'm trying to work out why my 8.1 system is slower than my 7.4 system
for importing data.
The import is a lot of insert into commands - it's a converted
database from another system so I can't change it to copy commands.
My uncommented config
Tim,
When I have done ODBC load tests with stats_block_level enabled on (20
mins. per test), I've seen about 3-4% performance hit. Your mileage may
vary.
Steve Poe
On Mon, 2006-03-13 at 18:49 -0500, mcelroy, tim wrote:
Good evening,
Does anyone know how much of a performance hit turning
[Snip]
shared_buffers = 256
Make this higher too. If this is a dedicated machine with 512 MB of
ram,
set it to something like 125000.
You may need to adjust shared memory settings for your operating
system.
See the manual for details.
Whoa. Maybe I'm wrong, but isn't each buffer
Gavin Sherry wrote:
On Tue, 14 Mar 2006, Chris wrote:
Hi all,
I'm trying to work out why my 8.1 system is slower than my 7.4 system
for importing data.
The import is a lot of insert into commands - it's a converted
database from another system so I can't change it to copy commands.
snip
Frank Wiles wrote:
On Tue, 14 Mar 2006 12:24:22 +1100
Chris [EMAIL PROTECTED] wrote:
Gavin Sherry wrote:
On Tue, 14 Mar 2006, Chris wrote:
Hi all,
I'm trying to work out why my 8.1 system is slower than my 7.4
system for importing data.
The import is a lot of insert into commands -
Chris [EMAIL PROTECTED] writes:
Tons of difference :/
Have you checked that the I/O performance is comparable? It seems
possible that there's something badly misconfigured about the disks
on your new machine. Benchmarking with bonnie or some such would
be useful; also try looking at iostat 1
On Tue, 14 Mar 2006 12:42:21 +1100
Chris [EMAIL PROTECTED] wrote:
Different hardware.
7.4 is running on a 500MHz computer with 256M compared to 8.1 running
on a 2.6GHz with 512M.
Well when it comes to inserts CPU and RAM have almost nothing to do
with it. What are the hard disk
Tom Lane wrote:
Chris [EMAIL PROTECTED] writes:
Tons of difference :/
Have you checked that the I/O performance is comparable? It seems
possible that there's something badly misconfigured about the disks
on your new machine. Benchmarking with bonnie or some such would
be useful; also try
On Tue, 14 Mar 2006, Chris wrote:
The only other thing I can see is the old server is ext2:
/dev/hda4 on / type ext2 (rw,errors=remount-ro)
the new one is ext3:
/dev/hda2 on / type ext3 (rw)
this is actually a fairly significant difference.
with ext3 most of your data actually gets written
David Lang wrote:
On Tue, 14 Mar 2006, Chris wrote:
The only other thing I can see is the old server is ext2:
/dev/hda4 on / type ext2 (rw,errors=remount-ro)
the new one is ext3:
/dev/hda2 on / type ext3 (rw)
this is actually a fairly significant difference.
with ext3 most of your data
23 matches
Mail list logo
