> Old servers that housed 7.4 performed better than 8.1.4 version...are
> there any MAJOR performance hits with this version???
>
> I set the postgresql.conf setting to equal that of 7.4 and queries still
> run
> SLOW on 8.1.4...
We need to find a specific query that is slow now that was fast befo
Here are the requested lines...
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: free space map contains 786 pages in 297 relations
DETAIL: A total of 5408 page slots are in use (including overhead).
5408 page slots are required to track
On 9/20/07, smiley2211 <[EMAIL PROTECTED]> wrote:
>
> How do I know if there is BLOATING??? I just ran vacuum verbose;
>
> Yes, autovacuum is on.
Post the last 4 or 5 lines from vacuum verbose.
---(end of broadcast)---
TIP 6: explain analyze is your
> Sorry, I know this is probably more a linux question, but I'm guessing
> that others have run into this...
> I'm finding this rather interesting report from top on a Debian box...
> Mem: 32945280k total, 32871832k used,73448k free, 247432k buffers
> Swap: 1951888k total,42308k used,
How do I know if there is BLOATING??? I just ran vacuum verbose;
Yes, autovacuum is on.
Thanks...Michelle
--
View this message in context:
http://www.nabble.com/Upgraded-from-7.4-to-8.1.4-QUERIES-NOW-SLOW%21%21%21-tf4489502.html#a12807959
Sent from the PostgreSQL - performance mailing list a
Decibel! <[EMAIL PROTECTED]> writes:
> I'm finding this rather interesting report from top on a Debian box...
> Mem: 32945280k total, 32871832k used,73448k free, 247432k buffers
> Swap: 1951888k total,42308k used, 1909580k free, 30294300k cached
> So how is it that linux thinks that
Sorry, I know this is probably more a linux question, but I'm guessing
that others have run into this...
I'm finding this rather interesting report from top on a Debian box...
Mem: 32945280k total, 32871832k used,73448k free, 247432k buffers
Swap: 1951888k total,42308k used, 1909580k
Hi everybody,
Is there a way to find which query is doing large io operations and/or which
is using cached data and which is reading from disk. I need to see this on a
production server to localize a slow and resource eating query. The
pg_statio* tables are very handy, but don't help me at all in
On 9/20/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> effort is going. I'm guessing you'll see a lot of id in there.
sorry, meant wa (wait)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.
On 9/20/07, smiley2211 <[EMAIL PROTECTED]> wrote:
>
> No, I didn't UPGRADE it but that's what I inherited :( ...not sure of the
> code page stuff because I am not the one who did the upgrade...I'm not sure
> I know ENOUGH about POSTGRESQL to mess around with the codepage...
>
> Yes, I use vacuum an
No, I didn't UPGRADE it but that's what I inherited :( ...not sure of the
code page stuff because I am not the one who did the upgrade...I'm not sure
I know ENOUGH about POSTGRESQL to mess around with the codepage...
Yes, I use vacuum analyze...
Yes, I used the postgresql.conf of 7.4 and tried t
smiley2211 wrote:
Hello all,
Old servers that housed 7.4 performed better than 8.1.4 version...are there
any MAJOR performance hits with this version???
Are you using the default UNICODE encoding for your databases??
This could potentially translate into a performance hit (considerable?
Ma
Thanks again, Peter, for expanding on these points.
Peter Koczan wrote:
Anyway... One detail I don't understand --- why do you claim that
"You can't take advantage of the shared file system because you can't
share tablespaces among clusters or servers" ???
I say that because you can't s
Hello all,
Old servers that housed 7.4 performed better than 8.1.4 version...are there
any MAJOR performance hits with this version???
I set the postgresql.conf setting to equal that of 7.4 and queries still run
SLOW on 8.1.4...
I have perform maintenance tonight on the 8.1.4 server - any ideas
> Anyway... One detail I don't understand --- why do you claim that
> "You can't take advantage of the shared file system because you can't
> share tablespaces among clusters or servers" ???
I say that because you can't set up two servers to point to the same
tablespace (i.e. you can't have serve
My new server postgresql.conf is equal to the old one. I'm doubting this is a
hardware issue.
Googling with my hard HP Proliant ML 110 G3 I saw that IHC7 controller has some
problems, but looking and testing with hdparm it looks ok.
hdparm -tT /dev/sdaç
Timing cached reads: 1722 MB in 2.00 second
(SORRY FOR THE REPOST, I DON'T SEE MY ORIGINAL QUESTION OR ANY ANSWERS HERE)
My client "publishes" an "edition" of their DB from his production site to
his hosted web/db server. This is done by FTPing a backup of the DB to his
hosting provider.
Immediately after a "publication" (restore to we
(SORRY FOR THE REPOST, I DON'T SEE MY ORIGINAL QUESTION OR ANY ANSWERS HERE)
I am noticing that my queries are spending a lot of time in nested loops.
The table/index row estimates are not bad, but the nested loops can be off
by a factor of 50. In any case, they are always too high.
Are the o
About 5 months ago, I did an experiment serving tablespaces out of
AFS, another shared file system.
You can read my full post at
http://archives.postgresql.org/pgsql-admin/2007-04/msg00188.php
Thanks for the pointer! I had done a search on the archives, but
didn't find this one (strange,
[EMAIL PROTECTED] wrote:
> Hola Beto.
> I have no idea where to look for that configuration or settings.
In postgreSQL, the main settings are in .../pgsql/data/postgresql.conf
> Yesterday I red about some drivers problems with SATA disk working
> togheter with IDE devices with DMA.
>
> Mi server
Hola Beto.
I have no idea where to look for that configuration or settings.
Yesterday I red about some drivers problems with SATA disk working togheter
with IDE devices with DMA.
Mi server server is a Pentium VI 3.3 with hyper threading (enabled in BIOS), HP
Proliant ML 110.
Then I entered to t
21 matches
Mail list logo
