And here is that latest benchmark we did, using a 8 dual core opteron
Sun Fire x4600. Unfortunately PostgreSQL seems to have some difficulties
scaling over 8 cores, but not as bad as MySQL.
http://tweakers.net/reviews/674
Best regards,
Arjen
Arjen van der Meijden wrote:
Alvaro Herrera
Arjen van der Meijden wrote:
And here is that latest benchmark we did, using a 8 dual core opteron
Sun Fire x4600. Unfortunately PostgreSQL seems to have some difficulties
scaling over 8 cores, but not as bad as MySQL.
http://tweakers.net/reviews/674
ouch - do I read that right that even
Stefan Kaltenbrunner wrote:
ouch - do I read that right that even after tom's fixes for the
regressions in 8.2.0 we are still 30% slower then the -HEAD checkout
from the middle of the 8.2 development cycle ?
Yes, and although I tested about 17 different cvs-checkouts, Tom and I
weren't
Arjen van der Meijden wrote:
And here is that latest benchmark we did, using a 8 dual core opteron
Sun Fire x4600. Unfortunately PostgreSQL seems to have some difficulties
scaling over 8 cores, but not as bad as MySQL.
http://tweakers.net/reviews/674
Hmm - interesting reading as always
Hi All,
I tried posting this last week but it has not come through yet, so please
excuse me if there is a double post.
We're having some issue's with the vacuum times within our database
environment, and would like some input from the guru's out there that could
potentially suggest a better
Bruce McAlister wrote:
Over time we have noticed increased response times from the database which
has an adverse affect on our registration times. After doing some research
it appears that this may have been related to our maintenance regime, and
has thus been amended as follows:
[1]
Joshua D. Drake wrote:
Geoffrey wrote:
Guillaume Smet wrote:
On 2/23/07, Geoffrey [EMAIL PROTECTED] wrote:
As I've heard. We're headed for 8 as soon as possible, but until we get
our code ready, we're on 7.4.16.
You should move to at least 8.1 and possibly 8.2. It's not a good idea
to
Hi Heikki,
Thanks for the reply.
The RAID array was implemented due to a projected growth pattern which
incorporate all 18 of our databases. The sizings I mentioned only refer to 1
of those databases, which, is also the most heavily used database :)
If I understand you correctly, we could in
Not quite a performance question, but I can't seem to find a simple answer
to this. We're using 8.1.4 and the autovacuum daemon is running every 40
seconds cycling between 3 databases. What is the easiest way to disable the
autovacuumer for a minute or two, do some other work, then re-enable
Bruce McAlister [EMAIL PROTECTED] writes:
[1] AutoVacuum runs during the day over the entire PostgreSQL cluster,
Good, but evidently you need to make it more aggressive.
[2] A Vacuum Full Verbose is run during our least busy period (generally
03:30) against the Database,
[3] A Re-Index on
Aidan Van Dyk wrote:
* Heikki Linnakangas [EMAIL PROTECTED] [070305 09:46]:
In fact, getting rid of vacuum full, or changing it to work like
cluster, has been proposed in the past. The use case really is pretty
narrow; cluster is a lot faster if there's a lot of unused space in the
table, and
Arjen van der Meijden wrote:
Stefan Kaltenbrunner wrote:
ouch - do I read that right that even after tom's fixes for the
regressions in 8.2.0 we are still 30% slower then the -HEAD checkout
from the middle of the 8.2 development cycle ?
Yes, and although I tested about 17 different
If you want to disable it only for some tables, you can put special
values into pg_autovacuum. This won't disable the autovacuum daemon, but
some of the tables won't be vacuumed.
Tomas
Not quite a performance question, but I can't seem to find a simple
answer to this. We're using 8.1.4 and
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Arjen van der Meijden wrote:
Stefan Kaltenbrunner wrote:
ouch - do I read that right that even after tom's fixes for the
regressions in 8.2.0 we are still 30% slower then the -HEAD checkout
from the middle of the 8.2 development cycle ?
Yes,
Ravindran G-TLS,Chennai. wrote:
Note: Please bear with us for the disclaimer because it is automated in
the exchange server.
Regards,
Ravi
FYI, we are getting closer to rejecting any email with such a
disclaimer, or emailing you back every time saying we are ignoring the
disclaimer.
Dear all,
After many tests and doc reading, i finally try to get help from
you...
Here is my problem. With some heavy insert into a simple BD (one
table, no indexes) i can't get better perf than 8000 inserts/sec. I'm
testing it using a simple C software which use libpq and which use:
- Insert
Hi all,
Do someone already had some problem with performances using a pentium
D (64 bits) and postgres 8.2.3 on a redhat enterprise update 2 ?
I did the install from sources and nothing change... I have a RAID 0
for data and 3Gb of RAM and my inserts rate is quite low, 8333 inserts/
sec (lower
Really appreciate all of the valuable input. The current server has the
Perc4ei controller.
The impression I am taking from the responses is that we may be okay with
software raid, especially if raid 1 and 10 are what we intend to use.
I think we can collect enough information from the archives
Tom Lane wrote:
Carlos Moreno [EMAIL PROTECTED] writes:
I would have expected a mind-blowing increase in responsiveness and
overall performance. However, that's not the case --- if I didn't know
better, I'd probably tend to say that it is indeed the opposite
(performance seems to have
Hello,
I have noticed a strange performance regression and I'm at a loss as
to what's happening. We have a fairly large database (~16 GB). The
original postgres 7.4 was running on a sun v880 with 4 CPUs and 8 GB
of ram running Solaris on local scsi discs. The new server is a sun
Opteron box
Hi ,
I want to know about hibernate left join,
Is their any way to do left join in hibernate ?.
Please give me an example of hibernate left join with its maaping
Thanks Regards
Bholu.
---(end of broadcast)---
TIP 4: Have you searched our list
Hi Ben,
Thanks for you answer.
I was thinking about CPU speed bottleneck because one of the CPU load
was always quite low on the server (Pentium D, dual core) and on the
other hand, the CPU load on my laptop was always very high. After some
more testing (using a threaded client software which
I suspect the difference is your disk subsystem. IDE disks (in your laptop
I assume) quite often (almost always!!) ignore fsync calls and return as
soon as the data gets to the disk cache, not the physical disk. SCSI disks
are almost always more correct, and wait until the data gets to the
Hi, I'm new to tuning PostgreSQL and I have a query that gets slower
after I run a vacuum analyze. I believe it uses a Hash Join before
the analyze and a Nested Loop IN Join after. It seems the Nested
Loop IN Join estimates the correct number of rows, but underestimates
the amount of
I have problems with queries over tsearch index.I have a table of books, with
120 registers. I have created an GIST index over the title and subtitle,
CREATE INDEX idxts2_titsub_idx ON public.libros USING gist
(idxts2_titsub);
Your query didn't use index that you are created..
After
* Heikki Linnakangas [EMAIL PROTECTED] [070305 09:46]:
If that is the case, why would anyone use the vacuum full approach if they
could use the cluster command on a table/database that will regen these
files for you. It almost seems like the vacuum full approach would, or
could, be
Hi, I'm new to tuning PostgreSQL and I have a query that gets slower
after I run a vacuum analyze. I believe it uses a Hash Join before
the analyze and a Nested Loop IN Join after. It seems the Nested
Loop IN Join estimates the correct number of rows, but underestimates
the amount of
On Sat, Mar 03, 2007 at 12:30:16PM +0100, Arjen van der Meijden wrote:
If you have a MegaCLI-version, I'd like to see it, if possible? That
would definitely save us some reinventing the wheel :-)
A friend of mine just wrote
MegaCli -AdpAllInfo -a0|egrep ' (Degraded|Offline|Critical
Jeff Cole [EMAIL PROTECTED] writes:
Hi, I'm new to tuning PostgreSQL and I have a query that gets slower
after I run a vacuum analyze. I believe it uses a Hash Join before
the analyze and a Nested Loop IN Join after. It seems the Nested
Loop IN Join estimates the correct number of
On 01.03.2007, at 13:40, Alex Deucher wrote:
I read several places that the SAN might be to blame, but
testing with bonnie and dd indicates that the SAN is actually almost
twice as fast as the scsi discs in the old sun server. I've tried
adjusting just about every option in the postgres config
Bruce Momjian wrote:
Ravindran G-TLS,Chennai. wrote:
Note: Please bear with us for the disclaimer because it is automated in
the exchange server.
Regards,
Ravi
FYI, we are getting closer to rejecting any email with such a
disclaimer, or emailing you back every time saying we are ignoring the
Bricklen Anderson wrote:
Bruce Momjian wrote:
Ravindran G-TLS,Chennai. wrote:
Note: Please bear with us for the disclaimer because it is automated in
the exchange server.
Regards,
Ravi
FYI, we are getting closer to rejecting any email with such a
disclaimer, or emailing you back
On 3/5/07, Guido Neitzer [EMAIL PROTECTED] wrote:
On 01.03.2007, at 13:40, Alex Deucher wrote:
I read several places that the SAN might be to blame, but
testing with bonnie and dd indicates that the SAN is actually almost
twice as fast as the scsi discs in the old sun server. I've tried
hatman wrote:
Dear all,
After many tests and doc reading, i finally try to get help from
you...
Here is my problem. With some heavy insert into a simple BD (one
table, no indexes) i can't get better perf than 8000 inserts/sec. I'm
testing it using a simple C software which use libpq and which
[EMAIL PROTECTED] wrote:
Hi ,
I want to know about hibernate left join,
Is their any way to do left join in hibernate ?.
Please give me an example of hibernate left join with its maaping
This isn't really a performance question, or even a PostgreSQL question.
You'll do better asking this on
35 matches
Mail list logo
