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 wrote
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 aft
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 real
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 Arjen
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 ap
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] AutoVac
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 upgr
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 e
Bruce McAlister wrote:
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 yo
Dear All,
I have to take backup of a database as a SQL file using the pg_dump
utility and I have to check the disk space
before taking the backup. Hence I need to estimate the size of the
pg_dump output.
The size given by pg_database_size procedure and the size of file
generated by pg_dump
vary t
am Mon, dem 05.03.2007, um 20:25:21 +0530 mailte Ravindran G-TLS,Chennai.
folgendes:
> Dear All,
>
> I have to take backup of a database as a SQL file using the pg_dump utility
> and
> I have to check the disk space
>
> before taking the backup. Hence I need to estimate the size of the pg_dump
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 it?
"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-In
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, an
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 differen
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 th
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 cy
On 5-3-2007 21:38 Tom Lane wrote:
Keep in mind that Arjen's test exercises some rather narrow scenarios;
IIRC its performance is mostly determined by some complicated
bitmap-indexscan cases. So that "30% slower" bit certainly doesn't
represent an across-the-board figure. As best I can tell, the
Yeah, I'm hoping there's an easier way. I'd have to put several thousand
entries in the pg_autovacuum table only to remove them a few minutes later.
What I really want is to disable the daemon.
Any idea why I can't just simply set autovacuum to off?
Steve
On 3/5/07, Tomas Vondra <[EMAIL PROTE
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 pre
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 tha
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 d
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 wi
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 doe
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 phy
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 time
>
> 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.
* 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, b
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 time
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 Disks
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,
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
On 05.03.2007, at 19:56, Alex Deucher wrote:
Yes, I started setting that up this afternoon. I'm going to test that
tomorrow and post the results.
Good - that may or may not give some insight in the actual
bottleneck. You never know but it seems to be one of the easiest to
find out ...
c
Are you sure that:
SELECT count(distinct s.id) AS count_all
FROM symptoms s ,symptom_reports sr,users u
WHERE s.id=sr.symptom_id and sr.user_id=u.id and u.disease_id=1;
is as slow as
SELECT count(*) AS count_all
FROM symptoms
WHERE (1=1 and symptoms.id in (
select symptom_id from symptom_re
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 u
[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
42 matches
Mail list logo
