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 :-
>>> 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
"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%'
>> )
> Tha
>>> 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.
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 03/23/07 5:26 PM >>>
On Fr
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.
>>> 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" "
"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.
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:
> 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 algorith
"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".
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 index
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 :-
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 Co
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 sur
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 r
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)---
TI
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 what
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 t
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 applicatio
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 t
"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 supp
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 bloc
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
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
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:
s
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 + e
27 matches
Mail list logo
