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 act
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 t
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 t
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 d
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 "iosta
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 -
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"
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.
ne
On Mon, 13 Mar 2006, Dave Dutcher wrote:
> [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
[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
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
>
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 uncommente
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
bgwriter
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 the
Title: PG Statistics
Good evening,
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 on for debug but if they'
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 transactio
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 concur
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, w
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, DE.AM_
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%
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
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:
> 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 Herrerahttp
If I only insert data into a table, never update or delete, then I should never
have to vacuum it. Is that correct?
Thanks,
Craig
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
unsubscribe
---(end of broadcast)---
TIP 6: explain analyze is your friend
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)---
T
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 nor
27 matches
Mail list logo
