Just now reading u2 list from last couple weeks.
> From: Ray Wurlod
> Sent: Monday, October 16, 2006 7:52 PM
>
> ...dictionaries you can move
> I-descriptors to some other file, and reference them via "R"
> (remote) types. I can't find it documented, ...
I've also done that when I've n
Jeff Schasny <[EMAIL PROTECTED]> wrote on Thu, 19 Oct 2006 10:32:55
-0600
> Much as I hate to make editorial comments on a very nice
> writeup, I'd hate for you to go on misusing [sic].
Thanks for the full reference, Jeff. I would have said something if you
hadn't.
There are two other Latin abb
Mark Johnson wrote:
> In 1978 ... I recall him reviewing a FOR...NEXT loop that had the FOR
part in one
> frame and the NEXT part in another and he was spending time trying to
> put compilable code (not comments) in front of the FOR section in the
> hope that the both the FOR and NEXT were in the s
that programmer, especially
reviewing the TCL-STACK file (big brother) for the typed command.
FYI
Mark Johnson
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 19, 2006 11:51 AM
Subject: RE: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM &a
insure that all the other numbers are prime just for a
dissertation. It was for relative difference and an example only.
Thanks
Mark Johnson
- Original Message -
From: "Jeff Schasny" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 19, 2006 12:32 PM
Subject: Re: [U2] VOCLIB an
Much as I hate to make editorial comments on a very nice writeup, I'd
hate for you to go on misusing [sic].
From the wikipedia (and correct as far as I have always known):
/*Sic*/ is a Latin word meaning "thus", "so", or
"just as that". In writing, it is italicized and placed within square
b
Mark
>Today's numbers are downright staggering in the MV world.
A couple of weeks ago I had to repair a failed RedBack implementation.
The garbage collection wasn't running, and so their state file had grown to
being a mere 15,000 times undersized.
Strangely enough, this eventually led to co
ystem supporting 16 users with 32K of core memory anymore. Today's
numbers are downright staggering in the MV world.
My 101,1 cents
Mark Johnson
----- Original Message -
From: "Anthony W. Youngman" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, October 18, 2006 5:06 AM
Subject: Re: [U2] VO
In message
<[EMAIL PROTECTED]>, Adrian
Merrall <[EMAIL PROTECTED]> writes
And on, and on, until the particular bit of data is found.
So... (this being one of the overwhelmingly elegant things about the
Pickuverse) this means that in a properly sized hashed file NO MATTER
HOW BIG it only takes on
Yes, and this is where the art and work of dba comes in, as well as why one
of the biggest (imho) vulnerabilities of the mv market has been the lack of
conscious architecting, at least in legacy systems. Lumpy files are very
often the result of a programmer creating a record that can potentially
Adrian Merrall wrote on 10/17/2006 06:44:40 PM:
> But won't this only work if your data fits into the modulo that
> matches your page size? If your data is lumpy and doesn't nicely fit
> into the page size/file modulo selected you get level 1overflow and
> more disk IO.
Good point. And in case
And on, and on, until the particular bit of data is found.
So... (this being one of the overwhelmingly elegant things about the
Pickuverse) this means that in a properly sized hashed file NO MATTER
HOW BIG it only takes one disk read to get to any record given a known
key. Ask your local Oracle/Sy
This is generally why your group size and OS
page size should be the same (yes, I know...unless you have some kind of
giant records, or dynamic files, or any of the other "YaBut's").
> So...this school of thought says that modulo 1 is a good thing, and
> that it forces files into memory. The
Blocksize/pagesize defines how much one disk read will bring in to
memory at an OS level. The application calling for the disk read
(Universe in this case) will then look for the data its searching for in
memory and if it does not find it will request another disk read from
the OS. And on, and
> So...this school of thought says that modulo 1 is a good thing, and
> that it forces files into memory. The question is -- is the school of
> thought speculation, or is it true?
Briefly? The school was closed for lack of funding... It may have been a
private school.
Since uniVerse runs as a '
The OS page size is what determines how much is read into memory on each
disk read. So if your page size is 2k (not unusual) then only the first
2k of your dictionary is going to be read in the first disk read
regardless of your modulo. This is generally why your group size and OS
page size sho
So...this school of thought says that modulo 1 is a good thing, and
that it forces files into memory. The question is -- is the school of
thought speculation, or is it true?
On 10/16/06, Ray Wurlod <[EMAIL PROTECTED]> wrote:
Interestingly, at least in some flavors, you can do something similar
How many of you bother to tune your file dictionaries? (There is
another school of thought >that says leaving them with modulo 1 forces
the entire dictionary to be read into memory, >leading to more
efficient location of subsequent items. But if that were really the
case, don't >you think the d
Interestingly, at least in some flavors, you can do something similar with file
dictionaries. In IDEAL flavor you can move I-descriptors to some other file,
and reference them via "R" (remote) types. I can't find it documented, but it
did work when I tried it. I-descriptors are 20+ fields long
Continuing with Mark's Comment, which is very important...
When the SELECT portion of the run engine is figuring out what to do, it
looks:
1) First in the DICTionary of the file and then
2) In the VOC
So, if what you need is at the end of a VOC disk record, or in overflow
due to the lumpy VOC
20 matches
Mail list logo
