...this looks really easy to me
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 9: the planner will ignore your desire
constraints, and applied them after all the data are loaded, wouldn't
the problem just go away?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
On Mon, 1 Mar 2004, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
Can you explain how to do this? There is no reference to a plan in the
contract table; the constraint just checks to see that, if a contract
exists, there is at least one plan referencing that contract
FOREIGN KEY ( contract_id ) REFERENCES plan ( contract_id )
INITIALLY DEFERRED;
produces the error message:
UNIQUE constraint matching given keys for referenced table plan not found
Since a plan may have more than one contract.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974
information
outside of the database data directory in a form that's not easily
backed up, and not easily found by other utilities?
It's almost like people *don't* want to put this in the config file
or something
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http
set it, and you
have to make sure that program gets run before any startup, be it an
automated startup from /etc/rc on boot or a manual startup.
I want to have it it the config file.
Well, then we're agreed.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
the same thing. And naive
people won't chose the wrong way because they don't know any better.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
, or it will kill your performance. Remember also, that in
7.2.x, postgres will actually use almost three times the value you give
sort_mem (i.e., sort_mem of 32 MB will actually allocate close to 96 MB
of memory for the sort).
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http
not made completely
clear, that Berkley FFS defaults to synchronous meta-data updates,
but asynchronous data updates. You can also specify entirely
synchronous or entirely asynchronous updates. Linux ext2fs supports
only these last two modes, which is the problem.
cjs
--
Curt Sampson [EMAIL PROTECTED
redirected followups to the pgsql-performance list.
Avoiding cross-posting would be nice, since I am getting lots of
duplicate messages these days.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
combining
multiple indexes, so you often need to split your queries across
the two partitions of the table that have separate indexes.
Shall I subscribe to performance?
Yes, you really ought to. The list is [EMAIL PROTECTED]
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http
noticable
improvement for not too much implementation effort.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't
On Sun, 19 Jan 2003, [ISO-8859-1] Hans-J$B|(Brgen Sch$Bv(Bnig wrote:
(B
(B + people measure postgresql by the speed of bulk imports
(B
(B This is a good point. I can complete agree. What we might need is
(B something called "SQL Loader" or so. This may sound funny and it doesn't
(B make
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
by other indexes with parallel
sorts rather than having to generate the primary key on one CPU (while
the other remains idle), wait while that completes, generate two more
indices, and then generate the last one .
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
about running out of address
space when you do this on multiple large tables. (And yes, I know this
would actually be, map this 1 GB chunk of this large table in the
current postgres implemenation.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know
system
force you to declare specific a specific object-ID column, if that's
what it takes. So long as you've got a candidate key, even if it's not
the primary key, you're fine.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age
On Fri, 23 Jan 2003, Hannu Krosing wrote:
Curt Sampson kirjutas N, 23.01.2003 kell 17:42:
If the OS can handle the scheduling (which, last I checked, Linux couldn't,
When did you do your checking ?
(just curious, not to start a flame war ;)
This was perhaps a year or so ago. IBM had some
you think X Y.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
multiple CPUs: so long as you've got lots
of connections with the load distributed among them, it's dependent on
the OS, postgres. If the OS can handle the scheduling (which, last I
checked, Linux couldn't, at least not without patches), eight or sixteen
CPUs will be fine.
cjs
--
Curt Sampson [EMAIL
before the variable-length fields.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you searched our list
(This response sent only to hackers.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
maintain that
if something does need something like of OIDs, it should be declared
explicitly in the database schema (as you have to do in other DBMSes)
and not use a hidden feature.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark
unless the user
asks for it, and b) multi-column primary keys work just fine.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
();
case | case | case
--+--+--
-999 | -999 | -999
(1 row)
(You get the same result if you delete the SELECT INTO line above.)
Am I misunderstanding something here, or is this a bug?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know
';
SELECT * FROM t2();
...produces rows with nulls in them.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 3: if posting
? Isn't
that just the same thing as storing IPv4 and IPv6 addresses together?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
to be
impractical, and thus is generally not used. Certainly you cannot route
to arbitrary v4 hosts using a v6 address.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end
not on Xenix, SCO Unix, any of the BSDs, Linux,
SunOS, Solaris, and Tru64 Unix.
(I'm talking about the flock system call, here.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
running both IPv4 and IPv6 on the hosts that interoperate.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 3: if posting
A ktrace would be helpful. Also, it would be helpful if you tried doing
an initdb to a directory on the filer to see if you can even create a
database cluster, and tried doing that or rsyncing and accessing your
data over NFS with a NetBSD system as the NFS server.
cjs
--
Curt Sampson [EMAIL
On Fri, 31 Jan 2003, Bruce Momjian wrote:
Also, I have heard a lot of people reocommending RAID 0+1 or 1+0 as a
good mix of reliability and performance.
Right. Striping across mirrored drives will definitely be better, but
you can't do that with only three drives.
cjs
--
Curt Sampson [EMAIL
or why not.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
to the process, in which
case one would think that a child doing an unlock should not affect the
parent, because it's a different process
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
, if someone
can point out particular parts of postgres that would fail over NFS.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
as a service?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Sun, 2 Feb 2003, Kurt Roeckx wrote:
On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
Sure. But you still want to be able to say (and can say, in some [many?]
socket API implementations) that you want to accept only IPv4 or only IPv6
connections. I also want to be able
. So long as you have the ability to distinguish where you listen
by both protocol and address, it's easy to be as secure as you need to be.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
sure the whole idea is worth persuing. (Though
I guess I should find out what NetBSD is really doing, and fix the
manual pages correspond to reality.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
of the postgres release-signing key to have
taken care of the key and have been careful about signing releases
with it?
Even if you extend this chain by a couple of people, that's trust in a
lot fewer people than you're going to need if you want to trust an MD5
signature.
cjs
--
Curt Sampson [EMAIL
-public background and I'm not dead certain that I could tell his voice
from a similar one. The same is not true when it comes to doing this with
some of my close friends.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're
do that.
Personally, I'm all for breaking backwards compatability (as I usually
am :-)) but could quite easily live with specifying all most hosts as
n.n.n.n/32 forever into the future, too.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know
difficult.
Someone can easily change an MD5 signature file that's sitting right next
to a binary on an FTP server. Someone can not easily change a PGP key that's
already sitting in your keyring on your computer.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
is stored with the item to be secured (i.e.,
on the same FTP server) and is unsigned, it is just as subject to
modification as the item itself, and provides no extra security.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age
of
some data, but that the time and means of acquisition of that hash are
entirely different between the two.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end
two or more. This is commonly done in
financial circles.
Hm. Splitting the key into parts is a very interesting idea, but I'd
be interested to know how you might implement it without requiring
everybody to be physically present at signing.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737
, because
you can't change the passphrase on the copy of the key he may have made.
A passphrase is like a lock on your barn door. After you've given
someone the key and he's gone in and taken the cow, changing the lock
gives you no protection at all.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90
On Wed, 11 Feb 2003, Greg Copeland wrote:
On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
[Re: everybody sharing a single key]
This issue doesn't change regardless of the mechanism you pick. Anyone
that is signing a key must take reasonable measures to ensure the
protection of their key
portability, too.
For example, mmap is a POSIX standard, whereas shmget is only an X/Open
standard. That makes me suspect that mmap is more widely available on
non-Unix platforms. (But I could be wrong.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you
I, personally, also think it makes more sense to pass to the postmaster
a configuration file that contains all the rest of the information about
the database system, including the disk locations of the various data
directories and whatnot.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737
decides
that they are good candidates to be paged out. I would imagine that
Windows does the same.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
On Wed, 12 Feb 2003, [ISO-8859-1] Hans-J$B|(Brgen Sch$Bv(Bnig wrote:
(B
(B Be careful with sort_mem - this might lead to VERY unexpected results. I
(B did some testing on my good old Athlon 500 with a brand new IBM 120 Gigs
(B HDD. Reducing the sort_mem gave me significantly faster results
that might potentially be a half terrabyte of
data, and is not infrequently several gigabytes or more, is pretty
system-depenendent.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
stuck where we are now all the time: you have
to just put it somewhere and hope that, if someone else needs to find
it, they can.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
it
separately on all of the others?
Typically, I want my favourite non-OS utilities on all machines, not
just one. (Even if I don't use them on all machines.) Thus /usr/local is
for site-local stuff.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you
such a rollback at all, except on an entire database,
because of the potential integrity violations. The best you could do
would be to generate SQL for the changes you'd need to get back to the
previous point, and see if you can execute these changes.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90
to deal with.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
for all processes.
I don't believe that the shared memory is not locked to a specific VM
address for every process. There's certainly no reason it needs to be.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light
with a full backup that is ok, and once you've successfully applied
all the transactions in the log, you know it will be ok again, so any
intermediate states during the restore where integrity is not maintained
are not a problem.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http
On Sat, 15 Feb 2003, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
... But there's really no need for all fifty of those,
if you don't mind not being able to restore to any time before the
current time.
Which, of course, is exactly the point of PITR designs.
When you know
be nearly so dramatic.)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
of the page somewhere.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
On Mon, 17 Feb 2003, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
If it's any kind of a serious problem, maybe it would be worth keeping
a CRC of the header at the end of the page somewhere.
See past discussions about keeping CRCs of page contents. Ultimately
I think it's
for, either. Maybe, if anybody still cares next time the page layout
is changed, pop it in with whatever else is being changed.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
was not partially
written.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
that it would be possible for the database to
transparently implement this using the optimisation described.
Given that, maybe one could just add another keyword to the REFERENCES
statement that would actually do the reference with a pointer?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http
or portable to try to escape parameters yourself.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you searched our list
use this capability automatically.
Well, if there's little or no performance impact, I would say that
the driver should always use this capability with PreparedStatement
objects. If there is a performance impact, perhaps a property could
turn it on and off?
cjs
--
Curt Sampson [EMAIL PROTECTED
on it,
and bring it back on-line again when done? This would get rid of
the logging overhead, locking overhead, and that sort of stuff,
and in theory might be able to get you something approaching
disk-speed data imports.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
your MySQL server crashes and your client finds that half
his data is corrupted...
If there are no updates, why would anything be corrupted? At any
rate, I can always restore from backup, since little or nothing
would be lost.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http
are added, but it's definitely better to
vaccum before the indexes are added.
Thanks. This is the kind of useful information I'm looking for. I
was doing a vacuum after, rather than before, generating the indices.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
not sure that creating indicies
would be any faster than just doing it after the tablespace is
attached.)
This would be particularly useful for fast restores of backups.
Downtime while doing a restore is always a huge pain for large
databases.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737
pg_restore.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
, or roll it foward
to partial completion and then figure out where to restart your import.
This seems especially likely if you can restore only the files relating
to the table that was actually damanaged.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you
in the last five years or so?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you searched our list archives
and a lot of workload before that becomes the problem.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you
still
including Berkeley source.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Fri, 19 Apr 2002, Sander Steffann wrote:
I can't think of a reason that [creation of] temp tables should
be prevented.
Maybe to keep hostile users from filling up your disk?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new
[I've moved this discussion about changing the line pointer from four
bytes to two from -general to -hackers, since it's fairly technical.
The entire message Tom is responding to is appended to this one.]
On Sat, 20 Apr 2002, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
... Then we
be unnecessary.
Really? How would things work without it?
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 2: you can
? I'm not sure. :-)
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
On Sat, 20 Apr 2002, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
While we're at it, would someone have the time to explain to me
how the on-disk CommandIds are used?
To determine visibility of tuples for commands within a transaction.
Just as you don't want your transaction's
one dives into the source, one already has a
good idea of what one's looking at.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
the data
that I need to insert. If it fits, exactly, I use it. If not, I
need to extend the line pointer array by one and make that point
to the remaining free space in the block of free space I used.
If a big enough block of free space doesn't exist, I compact the
page and try again.
cjs
--
Curt
know if there are any other places where
a user can eat resources, but the more I think about it, the more
complicated it gets. :-(
Yeah, exactly.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
care to make
any real assertions there.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 3: if posting/reading through
a
very easy root exploit...]
That's not a downside at all. If an exploit exists, you need only
try it, and it works or it doesn't.
In fact, it's an upside becuase it allows someone who doesn't have
exploit code more easily to determine whether or not he might be
vulnerable.
cjs
--
Curt Sampson
-running postgres system, we've got
really, really fast import/export capability.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
request on the logical level, via a system call.
I was refering to generating a physical I/O request, which a logical
I/O reqeust may or may not do.
So if you would please go back and tackle my argument again, based
on my clarifications above
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90
that uses raw
partitions and deals with its own buffer caching? This has the potential
to be a lot more efficient, since the database server knows much more
about its workload than the operating system can guess.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
of the things (using raw paritions, read-ahead,
free-behind, etc.) just drop out of that one idea.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
system, is a myth. If you are executing one
query and the system is doing only that query, you may be right.
No, it's very real, because your sequential read will not be broken up.
If you think it will, let me know which operating systems this
happens on, and how exactly it happens.
cjs
--
Curt
efficiently.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Wed, 24 Apr 2002, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
Grabbing bigger chunks is always optimal, AFICT, if they're not
*too* big and you use the data. A single 64K read takes very little
longer than a single 8K read.
Proof?
Well, there are various sorts of proof
undertaking, and looking
at our TODO list, I am not sure if it is worth it right now.
Right. I'm not trying to say this is a critical priority, I'm just
trying to determine what we do right now, what we could do, and
the potential performance increase that would give us.
cjs
--
Curt Sampson [EMAIL
On Thu, 25 Apr 2002, Curt Sampson wrote:
Here's the ratio table again, with another column comparing the
aggregate number of requests per second for one process and four
processes:
Just for interest, I ran this again with 20 processes working
simultaneously. I did six runs at each blockread
filesystem is divided into
cylinder groups (though these days the groups don't necessarially
match the physical cylinder boundaries on the disk) and a file's
i-node entry is kept in the same cylinder group as the file's data,
or at least the first part of the it.
cjs
--
Curt Sampson [EMAIL
On Thu, 25 Apr 2002, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
1. Theoretical proof: two components of the delay in retrieving a
block from disk are the disk arm movement and the wait for the
right block to rotate under the head.
When retrieving, say, eight adjacent blocks
majority of circumstances it does.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ
think so, because the smaller block size is definitely
better for random I/O.
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast
1 - 100 of 241 matches
Mail list logo
