On Friday 23 March 2007 03:20, Matt Smiley wrote:
My company is purchasing a Sunfire x4500 to run our most I/O-bound
databases, and I'd like to get some advice on configuration and tuning.
We're currently looking at: - Solaris 10 + zfs + RAID Z
- CentOS 4 + xfs + RAID 10
- CentOS 4 + ext3
Michael Stone schrieb:
On Thu, Mar 22, 2007 at 06:27:32PM +0100, Tino Wildenhain wrote:
Craig A. James schrieb:
You guys can correct me if I'm wrong, but the key feature that's
missing from Postgres's flexible indexing is the ability to maintain
state across queries. Something like this:
Hi
I'm going to install a new server and I'm looking for some advice
about how I can help my database performing at its best. I'll be using
a redhat ES 4 on a dual core opteron with 2 SCSI 10.000rpm disks in
RAID1.
The first question I have is, since I'd strongly prefer to use
postgresql 8.1 or
On Fri, Mar 23, 2007 at 01:01:02PM +0100, Tino Wildenhain wrote:
This discussion is a bit theoretical until we see the actual problem
and the proposed solution here.
It's good to see you back off a bit from your previous stance of
assuming that someone doesn't know what they're doing and that
Thanks Dimitri! That was very educational material! I'm going to think out
loud here, so please correct me if you see any errors.
The section on tuning for OLTP transactions was interesting, although my OLAP
workload will be predominantly bulk I/O over large datasets of
mostly-sequential
Paolo Negri [EMAIL PROTECTED] writes:
The first question I have is, since I'd strongly prefer to use
postgresql 8.1 or 8.2 instead of the 7.4 that comes with redhat, if
someone else is using with success third party rpms with success in
business critical applications.
Red Hat does support
On Thursday 22 March 2007 19:46, Michael Stone wrote:
On Thu, Mar 22, 2007 at 07:24:38PM +0100, Dimitri wrote:
you're right until you're using a single disk :)
Now, imagine you have more disks
I do have more disks. I maximize the I/O performance by dedicating
different sets of disks to
Tom Lane wrote:
Paolo Negri [EMAIL PROTECTED] writes:
The first question I have is, since I'd strongly prefer to use
postgresql 8.1 or 8.2 instead of the 7.4 that comes with redhat, if
someone else is using with success third party rpms with success in
business critical applications.
Red
On Mon, 2007-03-19 at 06:02, Ruben Rubio wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Vacuum full is very slow for me . I dont know how to speed it up. It
takes between 60 and 90 minutes.
I have set up autovacuum but I also run vacuum full once per week.
Note two things.
Michael Stone schrieb:
On Fri, Mar 23, 2007 at 01:01:02PM +0100, Tino Wildenhain wrote:
This discussion is a bit theoretical until we see the actual problem
and the proposed solution here.
It's good to see you back off a bit from your previous stance of
assuming that someone doesn't know
On Fri, Mar 23, 2007 at 04:37:32PM +0100, Dimitri wrote:
Speed-up x4 is obtained just because single vacuum process reaching max
80MB/sec in throughput
I'd look at trying to improve that, it seems very low.
Mike Stone
---(end of broadcast)---
I'm posting this to performance in case our workaround may be of benefit to
someone with a similar issue. I'm posting to hackers because I hope we can
improve our planner in this area so that a workaround is not necessary. (It
might make sense to reply to one group or the other, depending on
Hi,
I have two queries that are very similar, that run on the same table
with slightly different conditions. However, despite a similar number
of rows returned, the query planner is insisting on a different
ordering and different join algorithm, causing a huge performance
hit. I'm not
Run VACUUM ANALYZE and see if the cost estimates became close to the
effective rows. This could make it faster.
2007/3/23, Noah M. Daniels [EMAIL PROTECTED]:
SLOW:
Merge Right Join (cost=1138.78..460482.84 rows=2993 width=405)
(actual time=1244745.427..1245714.571 rows=39 loops=1)
Merge
I try to change my database server from the older one ie. 2Cpu Xeon 2.4 32
bit 4Gb SDram Hdd SCSI RAID 5 and FC 3 ix86 with 7..4.7 PG to the newer one
with 2CPU Xeon 3.0 64 Bit 4Gb DDRram SCSI Raid5 and FC6 X64 PG 8.14 and try
to use rather the same parameter from the previous postgresql.conf :-
Not much of a difference, unfortunately... I still wonder why it's
doing the 'supplier' (slow) query using the merge right join.
the 'fast' query:
Nested Loop Left Join (cost=0.00..423342.71 rows=2481 width=410)
(actual time=100.076..6380.865 rows=1355 loops=1)
- Index Scan using
Noah M. Daniels [EMAIL PROTECTED] writes:
I have two queries that are very similar, that run on the same table
with slightly different conditions. However, despite a similar number
of rows returned, the query planner is insisting on a different
ordering and different join algorithm,
Kevin Grittner [EMAIL PROTECTED] writes:
explain analyze
SELECT A.adjustmentNo, A.tranNo, A.countyNo, H.date,
H.userId, H.time
FROM Adjustment A
JOIN TranHeader H ON (H.tranId = A.adjustmentNo AND
H.countyNo = A.countyNo AND H.tranNo = A.tranNo)
WHERE H.tranType = 'A'
AND
Tom,
You're right; this is postgres 8.0.8. Perhaps upgrading will solve
this issue. Is there any way to get this query to perform better in
postgres 8.0.8?
thanks!
On Mar 23, 2007, at 6:13 PM, Tom Lane wrote:
Noah M. Daniels [EMAIL PROTECTED] writes:
I have two queries that are very
Noah M. Daniels [EMAIL PROTECTED] writes:
You're right; this is postgres 8.0.8. Perhaps upgrading will solve
this issue. Is there any way to get this query to perform better in
postgres 8.0.8?
You could try reducing random_page_cost, but I'm not sure that will
help much.
On Fri, Mar 23, 2007 at 4:49 PM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
explain analyze
SELECT A.adjustmentNo, A.tranNo, A.countyNo, H.date,
H.userId, H.time
FROM Adjustment A
JOIN TranHeader H ON (H.tranId =
On Fri, Mar 23, 2007 at 05:49:42PM -0400, Tom Lane wrote:
We don't currently try to flatten EXISTS into a unique/join plan as we
do for IN. I seem to recall not doing so when I rewrote IN planning
because I didn't think it would be exactly semantically equivalent,
but that was awhile ago.
I don't understand -- TRUE OR UNKNOWN evaluates to TRUE, so why would the IN
need to continue? I'm not quite following the rest; could you elaborate or
give an example? (Sorry if I'm lagging behind the rest of the class here.)
-Kevin
Martijn van Oosterhout kleptog@svana.org 03/23/07
On Fri, Mar 23, 2007 at 5:26 PM, in message
[EMAIL PROTECTED], Kevin Grittner
[EMAIL PROTECTED] wrote:
I tried something which seems
equivalent, but it is running for a very long time. I'll show it with just
the explain while I wait to see how long the explain analyze takes.
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
If you want that, try rewriting the EXISTS to an IN:
AND (H.tranNo, H.countyNo) IN
(
SELECT D.tranNo, D.countyNo FROM TranDetail D
WHERE D.caseNo LIKE '2006TR%'
)
That's the good news. The bad news is that I
On Fri, Mar 23, 2007 at 6:04 PM, in message
[EMAIL PROTECTED], Peter Kovacs
[EMAIL PROTECTED] wrote:
On 3/23/07, Kevin Grittner [EMAIL PROTECTED] wrote:
[...]
That's the good news. The bad news is that I operate under a management
portability dictate which doesn't currently allow that
I try to change my database server from the older one ie. 2Cpu Xeon 2.4 32
bit 4Gb SDram Hdd SCSI RAID 5 and FC 3 ix86 with 7..4.7 PG to the newer one
with 2CPU Xeon 3.0 64 Bit 4Gb DDRram SCSI Raid5 and FC6 X64 PG 8.14 and try
to use rather the same parameter from the previous postgresql.conf :-
27 matches
Mail list logo
