into the array.
We've had some remarkably good experiences with our recently-acquired
EMC.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir?
--attr. John Maynard Keynes
---(end of broadcast
walk off a
short pier. Their service people sure _try_ hard in the field, but
some machines required three and four visits to fix.
I also find the Sun Opteron offering to be way overpriced compared to
the competition.
In case it's not obvious, I don't speak for my employer.
A
--
Andrew
On Wed, Nov 03, 2004 at 03:53:16PM -0500, Andrew Sullivan wrote:
and may bust your query out of the cache. Also, we'd need some more
Uh, the data you're querying, of course. Queries themselves aren't
cached.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were
to a relatively low level. What that ought to mean
is that, under heavy load, some queries will abort.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir?
--attr. John Maynard Keynes
---(end
nasty things to the cache. It is hoped
that nastiness is fixed in 8.0.
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broadcast)---
TIP 8: explain analyze is your friend
. Also, we'd need some more
info about how you've tuned this thing. Maybe check out the archives
first for some tuning pointers to help you.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook
imagine that there's going to be a lot of enthusiasm for hints, so
anything that isn't a sure-fire planner helper is a potential loss,
at least to me.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually
such a feature
too.
Sure enough, quoting the constants fixes the problem.
Is it a best practice to always quote constants?
No, but it's very useful in these cases. The problem is I believe
this is fixed in 8.0, BTW. See the FAQ, question 4.8
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I
On Tue, Oct 05, 2004 at 09:47:36AM -0700, Josh Berkus wrote:
As long as you're on x86, scaling outward is the way to go. If you want to
continue to scale upwards, ask Andrew Sullivan about his experiences running
PostgreSQL on big IBM boxes. But if you consider an quad-Opteron server
, at least when it comes to
managing the largish number of processes that Postgres requires.
If pure speed is what you're after, I have found that 2-way, 32 bit
Linux on P-IIIs compares very favourably to 4 way 64 bit Ultra SPARC
IIs.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact
a bad batch of Dell hardware recently, which makes
me second this opinion.
I should say, also, that my initial experience of AIX has been
extremely good. I can't comment on the fun it might involve in the
long haul, of course.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary
is not notoriously useful. You may want to have a look at
what the example stuff in the SE Toolkit tells you, or what you get
from sar. I believe you have to use a special kernel setting on
Solaris to mark shared memory as being ineligible for swap.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work
? How do I
configure that, for knowledge?
You don't. It'll automatically be in memory if (a) you have enough
memory, (b) you don't have anything else on the machine using the
memory, and (c) it's been read at least one time.
A
--
Andrew Sullivan | [EMAIL PROTECTED
a VACUUM FULL and a complete REINDEX of the system tables next.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin
, if anyone thinks it'll be worth having around.
FWIW, we use ours in production.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broadcast)---
TIP 8: explain analyze is your
On Wed, Mar 10, 2004 at 11:07:28AM -0500, Andrew Sullivan wrote:
At work, we have been doing a number of tests on 7.4. The
performance is such an improvement over 7.2 that the QA folks thought
there must be something wrong. So I suppose the defaults are ok.
I know, I know, replying
now. Again,
this is on 8, not 9.
At work, we have been doing a number of tests on 7.4. The
performance is such an improvement over 7.2 that the QA folks thought
there must be something wrong. So I suppose the defaults are ok.
A
--
Andrew Sullivan | [EMAIL PROTECTED
far nobody's come up with a
solution. There was a proposal to put in a special-case automatic
fix for int4/int8 in 7.4, but I don't know whether it made it in.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what
you told them
disposal.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister
On Thu, Feb 26, 2004 at 12:46:23PM +, teknokrat wrote:
I've read about the place. Would using -O3 be an improvement?
In my experience, it's not only not an improvement, it sometimes
breaks the code. That's on 8, though, not 9.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural
on the machine during those hours? Maybe VACUUM is
sucking up all your bandwidth. Or your backups. Or some other
cron job.
Note that 7.2 is pretty old. There are several performance
improvements in subsequent versions.
A
--
Andrew Sullivan
---(end of broadcast
the cache or when doing cache maintenance.
A
--
Andrew Sullivan
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
gave
me fits. But XFS was nice.
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
---(end of broadcast
be about
the degree of testing the filesystem has received on Linux. On the
other hand, I wouldn't be surprised if it were no worse than the
other options.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace
, on the principle of better
safe than sorry.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
buffers under certain perverse
loads is lousy database performance _precisely_ when we need it. I
expect some testing of this type some time in January.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL
patterns -- and at that very
moment, the power goes away -- the data that was reported to have been
on the disk, but which was actually _not_ on the disk, is no longer
anywhere. (Well, except in the past. But time travel was disabled
some versions ago. ;-)
A
--
Andrew Sullivan
and
pg_attribute more frequently than you might have thought.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304
.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
---(end of broadcast
.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
---(end of broadcast
On Thu, Nov 13, 2003 at 04:37:03PM -0500, Andrew Sullivan wrote:
Actually, this one's on an internal box, and I think 1.5 is too low
-- it's really just a pair of mirrored SCSI disks on a PCI controller
in this case. That does the trick, though, so maybe I'm just being
too conservantive.
I
On Wed, Nov 05, 2003 at 11:35:22AM -0600, [EMAIL PROTECTED] wrote:
The \timing psql command gives different time for the same query executed
repeatedly.
Why do you believe that the same query will always take the same time
to execute?
A
--
Andrew Sullivan 204
?
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
---(end of broadcast
On Wed, Oct 22, 2003 at 09:27:47PM -0400, Tom Lane wrote:
trace. What is causing that? Not VACUUM I don't think. It doesn't have
any huge memory demand. But swapping out processes could account for
What about if you've set vacuum_mem too high?
A
--
Andrew Sullivan
didn't know if the memory was
actually taken by vacuum at the beginning (like shared memory is) or
what-all happened.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P
on query echoing.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
similar is at work here.
Not that I've had a reason to play with 4G ix86 machines, anyway.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
Bruce's 2-way machine is
within that threshold.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
heavily on what you're trying to
optimise for and what platform you have. But I'm glad to hear
(again) that people seem to think the 25% too high for most cases. I
don't feel so much like I'm tilting against windmills.
A
--
Andrew Sullivan 204-4141 Yonge Street
started taking a long time. The buffer algorithm is just not that
clever, was my conclusion.
(Standard disclaimer: not a long, controlled test. It's just a bit
of gossip.)
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario
with the new
probe-to-set-shared-buffers bit at install time, I think the reports
of 400 billion times worse performance than MySQL will probably
diminish.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL
with the
concern. I'd rather have slow'n'stable than fast-but-broken.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
didn't work for gcc at the time.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
than 5
connections). It might be worth trying again, though, since we moved
to Sol 8.
Thanks for the result.
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
your database is
small. So you'll end up expiring potentially useful data in the
buffer.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
idea how to give it such intelligence.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
On Fri, Oct 03, 2003 at 02:24:42PM -0600, Rob Nagler wrote:
I've read some posts that says vacuum doesn't lock, but my experience
today indicates the opposite. It seemed that vacuum full analyze
VACUUM doesn't. VACUUM FULL does.
--
Andrew Sullivan 204-4141 Yonge
On Fri, Oct 03, 2003 at 11:49:03PM -0400, Tom Lane wrote:
What if said SELECTs are using the index in question?
That's a good reason to build a new index and, when it's done, drop
the old one. It still prevents writes, of course.
A
--
Andrew Sullivan 204-4141
_way_
cheaper than it used to be, though.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
On Mon, Sep 29, 2003 at 05:43:26PM -, [EMAIL PROTECTED] wrote:
Anyone have a rough idea of the costs involved?
I did a back-of-an-envelope calculation one day and stopped when I
got to $10,000.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
. The 7.2 branch is no
longer being maintained, so you really probably should use the 7.3
branch. I'm unaware of others having stability problems with 7.3.4,
so if you see them, you should find your core dump and talk to the
people on -hackers.
A
--
Andrew Sullivan 204
On Wed, Sep 03, 2003 at 06:08:57AM -0700, Azlin Ghazali wrote:
I find that PostgreSQL runs up to 10 times slower than MySQL. For small records
Have you done any tuning on PostgreSQL? Have you vacuumed, c.? All
the usual questions.
A
--
Andrew Sullivan 204-4141
On Thu, Aug 28, 2003 at 03:26:14PM -0600, scott.marlowe wrote:
My experience has been that once you get past 6 disks, RAID5 is faster
than RAID1+0.
Also depends on your filesystem and volume manager. As near as I can
tell, you do _not_ want to use RAID 5 with Veritas.
A
--
Andrew
. Nobody's ever been
able/willing to tell me.
A
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
with how the shared
memory is handled. You'll want to dig through the -general or
-hackers archives from somewhere between 9 and 14 months ago, IIRC.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL
in
the archives of this list for thoughts on how big that should be.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1
syntactic sugar for
text. In fact, text and varchar() are supposed to be exactly the
same.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
On Fri, Aug 29, 2003 at 01:19:35PM -0400, george young wrote:
Does anyone know how and when the actual release will happen?
See the erserver project on gborg. It's out. There's a list, too;
any problems, send 'em there.
A
Andrew Sullivan 204-4141 Yonge Street
write transactions per second is probably too much to ask for
any standard hardware.
But given that you are batching this once a week, and trying to avoid
big expenses, are you use this is the right approach? Perhaps you
should consider a redesign using COPY and such?
A
--
Andrew Sullivan
something like
metadata journalling. Maybe others have more time to spare.
perhaps even including performance metrics for *BSD. That, not
Linux-baiting, is the answer...
I didn't see anyone Linux-baiting.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS
have to have all
sorts of nice tools to cope with the things that (for instance) fsck
handles. I think the reaction of most developers has been, Why
reinvent the wheel?
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario
SELECTs, though, I can't see what
exactly might be causing you so much difficulty.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
usually write journalled or equivalent for this reason.
I think UFS with soft updates is a good example of this. You also
don't need complete journalling in most cases -- metadata is probably
sufficient, given fsync.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty
might want to
investigate expainding the statistics on the indexed column,
increasing the correlation through clustering, and other such tricks.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED
at managing very large
buffer sets.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304 x110
want to increase your FSM settings. See the
docs.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304
RAID boxes :-( ), putting WAL on a disk of its own
yielded something like 30% improvement in throughput on high
transaciton volumes. So it's definitely important in some cases.
A
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario
failure, you need 1 (or
some combination of 0 and 1, or 5).
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416
of thing in the
application come to regret it. You probably want to look somewhere
else to solve your performance difficulties from FKs.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED
everytime a new release comes out would be way too much work.
It's not clear that the RPMs will help you in ease of upgrade. More
precisely, be real sure you dump your database before upgrading major
versions (e.g. 7.3.x to 7.4.x).
A
--
Andrew Sullivan 204-4141 Yonge
results. If we discover
any more, I'll post it here.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
[EMAIL PROTECTED] M2P 2A8
+1 416 646 3304
101 - 171 of 171 matches
Mail list logo
