to see
whether those features could be incorporated without the same
complication.
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
know the system pretty well).
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
?
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
. Can you please advise how to create logical partitions?
I would listen to yourself before you listen to the expert. You sound
right to me :)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance
as
bad or worse than the problem it's trying to solve.
Ok, but the danger is that the OOM killer kills your postmaster. To
me, this is a cure way worse than the disease it's trying to treat.
YMMD c. c.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
effects to your database. So for good
Postgres operation, you want to run on a machine with the OOM killer
disabled.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
vacuuming?
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
, and is broken by applications doing DDL as part of the
regular operation.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http
to send spam is hardly hacking the
list.)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
) for adaptively choosing different
update strategies that do not incur the full MVCC overhead?
How would you pick? But one thing you could do is create the table
with a non-standard fill factor, which might allow HOT to work its magic.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564
transactions no MVCC bloat seems to occur and updates are faster.
Are you on 8.3? That may be HOT working for you. MVCC doesn't get
turned off if there are no other transactions (it can't: what if
another transaction starts part way through yours?).
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564
will work before you deploy to production. (The other way to
say that, of course, is Linux is only free if your time is worth
nothing. Substitute your favourite free software for Linux, of
course. ;-) )
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com
administrators, the accounting people
want to know why the free software costs so much.
If you depend on your systems, though, you should never deploy any
change, no matter how innocuous it seems, without testing.
I agree completely.
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
your
application and your database, in my experience.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to know about in the context (with
only 8Go of memory, I don't consider this a powerful box at all,
note). But why wouldn't it be on the same network? You're using the
network stack anyway, note: JVMs can't go over domain sockets.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
on that :).
I think you will find that no replication system will solve your
underlying problems. That said, I happen to work for a company that
will sell you a replication system to work with 8.1 if you really want
it.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http
On Mon, Apr 28, 2008 at 07:48:48PM +0530, Gauri Kanekar wrote:
Slony don't do automatic failover. And we would appreciate a system with
automatic failover :(
No responsible asynchronous system will give you automatic failover.
You can lose data that way.
A
--
Andrew Sullivan
[EMAIL
On Wed, Apr 16, 2008 at 11:48:21PM +0200, Thomas Spreng wrote:
What I meant is if there are no INSERT's or UPDATE's going on it
shouldn't
affect SELECT queries, or am I wrong?
CHECKPOINTs also happen on a time basis. They should be short in that case,
but they still have to happen.
--
On Tue, Mar 11, 2008 at 02:19:09PM +, Matthew wrote:
of rows with IS NULL, then someone changes a row, then you find the count
of rows with IS NOT NULL. Add the two together, and there may be rows that
were counted twice, or not at all.
Only if you count in READ COMMITTED.
A
--
Sent
On Tue, Feb 19, 2008 at 02:48:55PM +, Matthew wrote:
If there's not much write traffic, the WAL won't be used much anyway.
You still have checkpoints.
If you really don't care much about the integrity, then the best option is
probably to put the WAL on ramfs.
Um, that will cause the
On Tue, Jan 29, 2008 at 04:28:45PM +0200, Adrian Moisey wrote:
Seriously though, how do I try measure this?
Is autovacuum not going to work for your case?
A
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
On Fri, Jan 11, 2008 at 10:19:51AM -0500, Tom Lane wrote:
Given that the world is going to IPv6 in a few years whether you like it
or not, that seems pretty darn short-sighted to me.
Indeed. Even ARIN has finally started to tell people that IPv4 is running
out. There are currently significant
On Fri, Jan 11, 2008 at 05:02:36PM -0500, Michael Stone wrote:
networks), but there's a conspicuous lack of a type for (hosts). I
suppose if you really are sure that you want to store hosts and not
networks
Well, part of the trouble is that in the CIDR world, an IP without a netmask
can be
On Fri, Jan 11, 2008 at 02:38:27PM -0800, Steve Atkins wrote:
I don't think there's ambiguity about what an dotted-quad without a
netmask
means, and hasn't been for a long time. Am I missing something?
Well, maybe. The problem is actually that, without a netmask under CIDR,
the address
On Fri, Dec 21, 2007 at 12:09:28AM -0500, Merlin Moncure wrote:
Maybe a key management solution isn't required. If, instead of
strictly wrapping a language with an encryption layer, we provide
hooks (actors) that have the ability to operate on the function body
when it arrives and leaves
On Fri, Dec 21, 2007 at 12:40:05AM -0500, Tom Lane wrote:
whether there is a useful policy for it to implement. Andrew Sullivan
argued upthread that we cannot get anywhere with both keys and encrypted
function bodies stored in the same database (I hope that's an adequate
summary of his point
On Thu, Dec 20, 2007 at 03:35:42PM -0500, Merlin Moncure wrote:
Key management is an issue but easily solved. Uber simple solution is
to create a designated table holding the key(s) and use classic
permissions to guard it.
Any security expert worth the title would point and laugh at that
On Thu, Dec 20, 2007 at 01:45:08PM -0600, Roberts, Jon wrote:
Businesses use databases like crazy. Non-technical people write their own
code to analyze data. The stuff they write many times is as valuable as the
data itself and should be protected like the data. They don't need or want
many
On Thu, Dec 20, 2007 at 03:24:34PM -0600, Roberts, Jon wrote:
Actually, PostgreSQL already has column level security for pg_stat_activity.
Not exactly. pg_stat_activity is a view.
But I think someone suggested upthread experimenting with making pg_proc
into a view, and making the real
On Thu, Dec 20, 2007 at 05:04:33PM -0500, Merlin Moncure wrote:
right, right, thanks for the lecture. I am aware of various issues
with key management.
Sorry to come off that way. It wasn't my intention to lecture, but rather
to try to stop dead a cure that, in my opinion, is rather worse
checkpoint, I'm seeing transactions running 2-3 seconds.
During this time, writes are 5/minute.
What gives?
pg_dump? Remember that it has special locks approximately equivalent
(actually eq? I forget) with SERIALIZABLE mode, which makes things rather
different.
A
--
Andrew Sullivan
Old sigs
?
Probably by buying much faster disk hardware. You'll note that the query
plans you posted are the same, except for the actual time it took to get the
results back. That tells me you have slow storage. On subsequent runs,
the data is cached, so it's fast.
A
--
Andrew Sullivan
Old sigs will return
everything you need.
But are you sure there are _no other_ transactions open when you do that?
This could cause problems, and CLUSTER's behaviour with other open
transactions is not, um, friendly prior to the current beta.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue
to your user (or just connect as postgres
user) for the time being, while debugging this.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Wed, Nov 14, 2007 at 11:58:23AM -0500, Andrew Sullivan wrote:
No, every statement in psql is a transaction. Even SELECT. Every statement
Err, to be clearer, Every statement in psql is _somehow_ part of a
transaction; if you don't start one explicitly, the statement runs on its
own
that is doing something there (you won't see an UPDATE in
that case), or else something else is causing INSERTs to fail.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast)---
TIP 4: Have you searched our
. That should cause errors that you'd get in the log, presuming that
you have the log level set correctly.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
is the only way -- if you insert directly, it will happily insert
into that column. But it should cause an error to show in the log, which is
what's puzzling me.
A
--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke
---(end of broadcast
numbers of failed vacuums,
however, I suspect your problem is I/O. Vacuum churns through the
disk very aggressively, and if you're close to your I/O limit, it can
push you over the top.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
and its hard- and
firm-ware, as well as its ability to interact with the OS. I think
the best answer is sometimes yes.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
However important originality may be in some fields, restraint and
adherence to procedure emerge as the more significant virtues
\timing??? I don't get any time when using the
\timing option...
How so? It returns Time: N ms at the end of output for me.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition
. Is there any rule of
thumb?
Actually I set it to +-256M.
There has been Much Discussion of this lately on this list. I
suggest you have a look through the recent archives on that topic.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
for the EXPLAIN
ANALYSE to return, I assumed that the problem is one of impatience and
not clock cycles. After all, the gettimeofday() additional overhead
is still not going to come in on the order of minutes without a
_bursting_ huge query plan.
A
--
Andrew Sullivan | [EMAIL PROTECTED
you're going
to get your redundancy back is to go noticably slower :-(
will lose a very little bit in comparison. Andrew Sullivan had a
somewhat similar finding a few years ago on some old Solaris hardware
that unfortunately isn't at all relevant today. He basically found
that moving WAL off
an undemonstrated benefit and
probably a whole lot of new bugs?
A
--
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
that 6 drives in
RAID5, even if they're 15,000 RPM. The rotation speed is the least
of your problems in many RAID implementations.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
November.
--H.W. Fowler
to, but then the
INSERTing transaction rolls back, it leaves a dead tuple in its wake.
My guess, from your posted example, is that you have the latter case
happening, because you have removable rows (that's assuming you
aren't mistaken that there's never a delete or update to the table).
A
--
Andrew
was that, for high-contention workloads like the ones we
happened to be working on, an optimistic approach like Postgres-R is
probably always going to be a loser.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become
-- like maybe in a loop
-- would be better for your case.
A
--
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
more I/O, and actually more CPU wouldn't
hurt, because then you could run three VACUUMs on three separate
tables (on three separate disks, of course) and not have to switch
them off and on the CPU.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt
at least limit it to one list?
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
it, and since we're not, we can't possibly know about it,
right ;-) But there are some materials about why to use Postgres on
the website:
http://www.postgresql.org/about/advantages
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir
On Mon, Jun 18, 2007 at 02:38:32PM -0400, Andrew Sullivan wrote:
I've picked -advocacy.
Actually, I _had_ picked advocacy, but had an itchy trigger finger.
Apologies, all.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all
, that wasn't the case
for relatively small buffers; with the replacement of single-pass
LRU, that has certainly changed, but I'd be surprised if anyone
tested a buffer as large as 32G.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness
an exclusive lock, but the basic conceptual
problem is the same.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack.
--Scott Morris
---(end
*after* it has completed and postgres has told
me so by logging a slow query entry in my logs?
You can't :(
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis
at is to
see whether you are in fact hitting 100% of your I/O capacity and, if
so, what your options are for getting more room there.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The year's penultimate month is not in truth a good way of saying
November.
--H.W. Fowler
segments (maybe
partitions, maybe something else) would help, so I know for sure that
someone is working on a problem like this, but I don't think it's the
sort of thing that's going to come any time soon.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because
at it. But
it seems a waste to re-implement something that's already apparently
working for you in favour of something more expensive that you don't
seem to need.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions. What do you do sir
that certainly had a similar issue, but I couldn't
show you the data to prove it. Everyone who used it knew about it,
though.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off
On Wed, Jun 06, 2007 at 09:20:54PM +0200, Gunther Mayer wrote:
What the heck could cause such erratic behaviour? I suspect some type of
resource problem but what and how could I dig deeper?
Is something (perhaps implicitly) locking the table? That will cause
this.
A
--
Andrew Sullivan
that _other_ transactions don't get I/O
starved. (Make vacuum fast isn't in most cases an interesting
goal.)
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
, and so
doing things to improve the chances of correct storage is a good
idea.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 2
of queries
I bet that single disk is your problem. Iostat is your friend, I'd
say.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 1
scheduling safely, you have to be really
sure that you know what the other transactions are doing.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Information security isn't a technological problem. It's an economics
problem.
--Bruce Schneier
---(end of broadcast
On Sun, Nov 26, 2006 at 09:24:29AM -0500, Rod Taylor wrote:
attempt and fail a large number of insert transactions then you will
still need to vacuum.
And you still need to vacuum an insert-only table sometimes, because
of the system-wide vacuum requirement.
A
--
Andrew Sullivan | [EMAIL
restored, actually works.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Everything that happens in the world happens at some place.
--Jane Jacobs
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
urge you to take it to the Slony
list.)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Windows is a platform without soap, where rats run around
in open sewers.
--Daniel Eran
---(end of broadcast)---
TIP 5: don't forget to increase your
targets getting further behind?
3. Your backups from the slave aren't done with pg_dump,
right?
But I suspect Slony has a role here, too. I'd look carefully at the
slony tables -- especially the sl_log and pg_listen things, which
both are implicated.
A
--
Andrew Sullivan | [EMAIL PROTECTED
into this latter category.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack.
--Scott Morris
---(end of broadcast
.
The next thing I'd look for is OS-level performance problems.
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
just because ANALYSE will impose an
I/O load.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
--Alexander Hamilton
---(end of broadcast
for the
full report to come back, and therefore they'll end up flying blind
instead. (Note that the impatient is not always the person logged
in and executing the commands.)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what
you told them
the processor up to 99.9% active).
Are there any locks preventing the query from completing? I can't
recall how you check in 7.3, but if nothing else, you can check with
ps for something WAITING.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Unfortunately reformatting the Internet is a little more
or anything are happening automatically?
Anyway, I take it that there is no way to bypass the optimizer and
instruct PostgreSQL exactly how one wants the search performed?
No, there isn't.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success
.
A
--
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)---
TIP 2: Don't 'kill
...
And it doesn't work very well without changes to buffering. You need
both pieces to get it to work.
A
--
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
of storage, not the point of view of
the user).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The plural of anecdote is not data.
--Roger Brinner
---(end of broadcast)---
TIP 6: explain analyze is your friend
to FSM is worth (a) an exclusive lock and (b) the
loss of efficiency you get from having some preallocated pages in
tables.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
is figure out what your churn rate is on
tables, and count up how many disk pages that's likely to be. Give
yourself a little headroom, and the number of FSM pages is done, too.
This churn rate is often tough to estimate, though, so you may have
to fiddle with it from time to time.
A
--
Andrew
, the performance effect is positive. If you have VACUUM
FULLed table, inserts have to extend the table before inserting,
whereas in a table with some space reclaimed, the I/O effect of
having to allocate another disk page is already done.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my
make. Heck, I gave away a
box to charity only two weeks ago that would solve your problem
better than automatically issuing VACUUM FULL.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Information security isn't a technological problem. It's an economics
problem.
--Bruce Schneier
for any generic workload yet under 8.1 (although probably people know
them well enough for particular workloads).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well
On Tue, Jan 17, 2006 at 11:43:14AM -0500, Chris Browne wrote:
[EMAIL PROTECTED] (Andrew Sullivan) writes:
Because nothing that runs automatically should ever take an exclusive
lock on the entire database,
That's a bit more than what autovacuum would probably do...
Or even VACUUM FULL
to understand that.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George Orwell
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
? (I have a feeling that something along
the lines of what Tom Lane said would be a better answer -- I think
you need to be more clever, because I don't think this will ever work
well, on any system.)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes
?). Is this a time, for
example, when logrotate is killing your I/O with file moves?
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
space from the free
space map (because of that table turnover, which seems pretty
severe).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George Orwell
---(end of broadcast
using).
The painful part about tuning a production system is really that you
have to keep about 50 variables juggling in your head, just so you
can uncover the one thing that you have to put your finger on to make
it all play nice.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description
down a lot of dead tuples,
for instance, you'll peg your I/O even though you ought to have I/O
to burn.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George Orwell
---(end of broadcast
are nevertheless performing very well --
we did a load test that was pretty impressive. Also, Chris Browne
pointed me to this for the drivers:
http://sourceforge.net/projects/cciss/
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all
On Fri, May 06, 2005 at 02:39:11PM -0700, Mischa Sandberg wrote:
IBM, Sun and HP have their fairly pricey Opteron systems.
We've had some quite good experiences with the HP boxes. They're not
cheap, it's true, but boy are they sweet.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future
block other transactions, and this approach
will definitely run that risk.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
--Alexander Hamilton
, in my experience, is _very bad_ at managing context
switches. So you may not be merely I/O bound (although your other
reports seem to indicate that you are).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The whole tendency of modern prose is away from concreteness.
--George Orwell
case, I didn't have superuser access, so there wasn't
a danger; but I've heard sysadmins complain about this.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis
a
slave gives you a useless database dump.
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 3: if posting
for this, and is happy
to talk on the record about it.
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 9: the planner will ignore
in performance nearly as quickly as CPUs have.
Indeed. And you can go through an awful lot of budget buying solid
state storage ;-)
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
On Wed, Jan 19, 2005 at 10:42:26AM -0500, Alan Stange wrote:
I'm fairly sure that the pi and po numbers include file IO in Solaris,
because of the unified VM and file systems.
That's correct.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
When my information changes, I alter my conclusions
1 - 100 of 171 matches
Mail list logo