I wrote:
> Joins against partitioned tables suck in 8.1 :-(.
Actually ... while the above is a true statement, it's too flippant a
response for your problem. The reason the planner is going for a
mergejoin in your example is that it thinks the mergejoin will terminate
early. (Notice that the cos
"Mark Liberman" <[EMAIL PROTECTED]> writes:
> I have recently implemented table partitioning in our postgres 8.1 db. =
> Upon analyzing query performance, I have realized that, even when only a =
> single one of the "partitions" has to be scanned, the plan is =
> drastically different, and performs
Title: Why is plan (and performance) different on partitioned table?
Hi,
I have recently implemented table partitioning in our postgres 8.1 db. Upon analyzing query performance, I have realized that, even when only a single one of the "partitions" has to be scanned, the plan is drastically d
Tom Lane wrote:
Nolan Cafferky <[EMAIL PROTECTED]> writes:
But, I'm guessing that random_page_cost = 1 is not a realistic value.
Well, that depends. If all your data can be expected to fit in memory
then it is a realistic value. (If not, you should be real careful not
to mak
Nolan Cafferky <[EMAIL PROTECTED]> writes:
> But, I'm guessing that random_page_cost = 1 is not a realistic value.
Well, that depends. If all your data can be expected to fit in memory
then it is a realistic value. (If not, you should be real careful not
to make performance decisions on the basi
>My server is the HP DL585 (quad, dual-core Opteron, 16GB RAM) with 4 HD
bays run by a HP SmartArray 5i controller. I have 15 10K 300GB >drives
and 1 15K 150GB drive (don't ask how that happened).
Our server will be a DL385 (dual, dual-core Opteron, 16Gb RAM), and the
28 disks(10K 146Gb)in the MS
Tom Lane wrote:
The first-order knob for tuning indexscan vs seqscan costing is
random_page_cost. What have you got that set to?
This is currently at the default of 4. All of my other planner cost
constants are at default values as well. Dropping it to 1 drops the
estimated cost by a compa
Nolan Cafferky <[EMAIL PROTECTED]> writes:
> After some more digging on the mailing list, I found some comments on
> effective_cache_size. Bringing it up from the default of 1000 does pust
> the estimated cost for the index scan below that of the sequential scan,
> but not by much.
The first-
Questions:
* What can I do to reduce the estimated row count on the query?
* Why does clustering drive down the estimated cost for the index scan
so much? Does a change in correlation from .72 to 1 make that much of
a difference?
* Can I convince my query planner to index scan without clustering
guess who just bought a 3ware BBU on ebay...
Thanks for all the posts, consider me educated!
(on the importance of BBU on RAID controllers, anyway)
:)
Scott Marlowe wrote:
On Mon, 2006-05-01 at 13:22, Tom Arthurs wrote:
UPS does not protect against the tech behind the rack unplugging the
po
Title: Postgres 7.4 and vacuum_cost_delay.
Hi everyone.
I've got a quick and stupid question: Does Postgres 7.4 (7.x) support vacuum_cost_delay?
For all my googles and documentation reading I've determined it's not supported, only because I can't find a 7.x doc or forum post claiming other
On Mon, 2006-05-01 at 13:22, Tom Arthurs wrote:
> UPS does not protect against the tech behind the rack unplugging the
> power cable, or an accidental power cycle from exercising the wrong
> switch. :) Both are probably more common causes of failure than a total
> power outage.
>
> Erik Myllym
Title: Re: [PERFORM] hardare config question
We use the 3Ware BBUs and they’re very nice, they self monitor and let you know about their capacity if it’s a problem.
- Luke
On 5/1/06 11:43 AM, "Erik Myllymaki" <[EMAIL PROTECTED]> wrote:
good points, thanks.
Tom Arthurs wrote:
> UPS does not
UPS does not protect against the tech behind the rack unplugging the
power cable, or an accidental power cycle from exercising the wrong
switch. :) Both are probably more common causes of failure than a total
power outage.
Erik Myllymaki wrote:
I have been in discussion with 3ware support and
good points, thanks.
Tom Arthurs wrote:
UPS does not protect against the tech behind the rack unplugging the
power cable, or an accidental power cycle from exercising the wrong
switch. :) Both are probably more common causes of failure than a total
power outage.
Erik Myllymaki wrote:
I have
On May 1, 2006, at 1:58 PM, Erik Myllymaki wrote:
Of course now i am in a dangerous situation - using volatile write
cache without a BBU.
It should be against the law to make RAID cards with caches that are
not battery backed.
If I were to use a UPS to ensure a soft shutdown in the eve
A UPS will make it less likely that the system will reboot and destroy
your database due to a power failure, but there are other causes for a
system reboot.
With a BBU, the only component that can fail and cause catastrophic data
loss is the RAID itself.
With a UPS, you are additionally vulnerabl
I have been in discussion with 3ware support and after adjusting some settings,
the 3ware card in RAID 1 gets better performance than the single drive. I guess
this had everything to do with the write (and maybe read?) cache.
Of course now i am in a dangerous situation - using volatile write ca
I wrote:
> FWIW, my own experiments with tests like this suggest that PG is at
> worst about 2x slower than mysql for trivial queries. If you'd reported
> a result in that ballpark I'd have accepted it as probably real. 6x I
> don't believe though ...
Just for amusement's sake, I tried compiling
I'm running postgres 8.0.7, and I've got a table of orders with about
100,000 entries. I want to just look at the new orders, right now 104 of
them.
EXPLAIN ANALYZE
SELECT
order_id
FROM
orders
WHERE
order_statuses_id = (SELECT id FROM order_statuses WHERE id_name
= 'new'
>FWIW, my own experiments with tests like this suggest that PG is at
worst about 2x slower than mysql for trivial queries. If you'd reported
a result in that ballpark I'd have accepted it as probably real. 6x I
don't believe though ...
OTOH, my tests using BenchmarkSQL
(http://sourceforge.net/pr
On Fri, 2006-04-28 at 13:36, Greg Stumph wrote:
> Well, since I got no response at all to this message, I can only assume that
> I've asked the question in an insufficient way, or else that no one has
> anything to offer on our problem.
>
> This was my first post to the list, so if there's a bet
"Steve Woodcock" <[EMAIL PROTECTED]> writes:
> On 01/05/06, Scott Sipe <[EMAIL PROTECTED]> wrote:
>> So, my question is, before I do any further digging, is super-smack
>> flawed?
> Hmm, selects and updates of a 90k row table using the primary key, but
> no sign of a VACUUM ANALYZE...
Reasonably
On 01/05/06, Scott Sipe <[EMAIL PROTECTED]> wrote:
So, my question is, before I do any further digging, is super-smack
flawed?
Hmm, selects and updates of a 90k row table using the primary key, but
no sign of a VACUUM ANALYZE...
Cheers, Steve Woodcock
---(end of broadc
On Mon, May 01, 2006 at 03:05:54AM -0500, Scott Sipe wrote:
> So, my question is, before I do any further digging, is super-smack
> flawed?
It's sort of hard to say without looking at the source -- it certainly isn't
a benchmark I've heard of before, and it's also sort of hard to believe a
bench
I can't speak to "the access mode of the SQL statement" but it looks
like the index that you are looking for is an index on an expression,
as shown in:
http://www.postgresql.org/docs/8.0/static/indexes-expressional.html
You probably want a btree on UPPER(municipo), if that is the primary
query me
I've been attempting to tweak performance on a FreeBSD 6 server I'm
running that has both Postgresql 8.1 and Mysql 4.1 running
simultaneously.
To attempt to gauge performance I was directed to the super-smack
(http://vegan.net/tony/supersmack/) benchmark.
Testing gave results that showe
27 matches
Mail list logo
