The ! was just part of the data
The standard is here http://tools.ietf.org/html/rfc4180
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
charles_shaf...@ntn-bower.com
Sent: 07 July 2009 20:03
To: U2 Users List
We've recently implemented indexing into our application as a
replacement for our own custom indexes, so I'm at least a little bit
qualified to answer some of your questions:
* Number of indexes - no guidelines afaik. The update process seems fast
enough - certainly, every write triggers an
Be careful not to index on a foreign key, i.e. do not index a field that
is a tlookup or trans to another file.
An example is if custno is on the order header,and you xlate it to
order.line, do not index order.line by custno. It will not update
properly.
U2 indexing is such a breath of
When you have a file with 50 million records, it does not matter how
you build the or parse the dynamic array. A well sized work file will
run circles around the dynamic array.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org]
I don't agree. Disk access is inherently slower than RAM access.
Therefore a process that makes efficient use of RAM will be faster than
an equivalent algorithm making efficient use of disk.
In your case, it's just a matter of scale:
50 million records at (lets say) 14 bytes per ID plus the
Edward Brown wrote:
I don't agree. Disk access is inherently slower than RAM access.
Therefore a process that makes efficient use of RAM will be faster than
an equivalent algorithm making efficient use of disk.
In your case, it's just a matter of scale:
50 million records at (lets say) 14
Just a quick note on indexes... and kind of goes to the EMC question.
The location of the index is stored in header of the file itself! This can
lead to a problem if you have a copy of the data somewhere else
and try to use it. For example, we'll occasionally want to see how a
file/record
Maybe one of you would be willing to pull all these good posts on indexing into
a wiki article? It would be handy reference material and could save someone
from hours of pain can't get this stuff from reading the system docs.
http://212.241.202.162/U2UGWiki/moin.cgi/ForDevelopers
-Baker
In theory, I would have to agree with you. Who knows how all this stuff
really works under the hood. You have Unidata Shared memory management
and shared basic code server. We also have a huge SAN with a lots of
cache. Measuring performance and impacting it is different these days.
There are so
Robert Porter wrote:
Just a quick note on indexes... and kind of goes to the EMC question.
The location of the index is stored in header of the file itself! This can lead to a problem if you have a copy of the data somewhere else
and try to use it. For example, we'll occasionally want to see
In one test I did a couple of months back, I found that appending IDs to the
end of a dynamic array perfomed _much_ _much_ slower than a WRITESEQ to the end
of a disk file and the dynamic array wasnt even a 100 000 records long. We were
able to reduce the time required to produce a report from
Sorry yes, I was speaking of UV. There the data for the index is stored in
I_(filename) by default.
But inside the header of the actual file, there is a pointer to where the
indexes live.
So the indexes could live somewhere else by using the SET.INDEX command, if you
wanted to
move them for
Marco Manyevere wrote:
In one test I did a couple of months back, I found that appending IDs
to the end of a dynamic array perfomed _much_ _much_ slower than a
WRITESEQ to the end of a disk file and the dynamic array wasnt even a
100 000 records long. We were able to reduce the time required to
Kathleene,
Is this what you were referring to below? We also tried this approach with
no luck. The vector functions did work for us.
If I set this up wrong, please feel free to correct me :-)
Thanks!
ASSOC
0001 PH
0002 ST FT DEW
ST
0001 D
0002 2
0003
0004 Start
0005 8R
0006 M
0007
It's been a long time since I've been in hardware so I may be all off on
this, but, this could be possible because after it sends the WRITESEQ it's
basically up to the disk subsystem to actually do the writing. The written
sequential record get's put in the queue and the subsystem sends back a
Excellent idea, Baker. I'll work on that after this thread settles down. I
won't include the dynamic array vs. work file bits since that's not
directly related to indexing.
Brad Schrag
Maybe one of you would be willing to pull all these good posts on
indexing into a wiki article? It
Hi all,
I don't agree. Disk access is inherently slower than RAM access.
I think that this discussion started for Unidata and then got UniVerse
involved too but it might have been the other way around. Sadly, there is no
internals training material for Unidata so we have to guess what goes
Martin
Your test program on unidata 7.1 takes 1137 milliseconds - 1.1 seconds.
I changed it to use system(12), this is a better resolution clock on
unidata than TIME().
Interesting commentary on chunking. I believe (and I might be talking
out of my ar*e here) that chunking done with (system
I want to move to one of my earlier questions in this thread regarding
mixing indexed and non-indexed dictionary items, and if unidata is able
to use the indexed items at all in this circumstance:
Simple test:
One fairly big file:
Items - 473,000
Item size - 695 bytes on average
Indexed
All
Since we're already going off on a huge tangent re. indexing, it's worth
pointing out that if you're writing client side code in .Net the same
applies: strings are immutable and every change or append copies the string
in memory. That's why there is a StringBuilder class for appending to
Hi again Ed,
SELECT file WITH PRINT.DATE GT 01/04/2008 AND WITH ADDR LIKE 'A'0X
This query can be resolved with an index. Also, the optimiser will shuffle
the clauses to make best use of indices. Unidata had query optimisation
before UniVerse but I believe that essentially the same
Ha Ha a dev from IBM letting secrets out to ladybridge ;)
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin Phillips
Sent: 08 July 2009 20:57
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
Hi Symeon,
Ha Ha a dev from IBM letting secrets out to ladybridge ;)
Yes, it was a bit much to hope!!!
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
___
U2-Users mailing list
I took a stab at extracting and compiling index-related info from this
thread. It's not pretty, but it's a start. Feel very free to update,
restructure or change as seems appropriate.
http://212.241.202.162/U2UGWiki/moin.cgi/ForDevelopers
Brad.
U.S. BANCORP made the following annotations
I just tried this example on Universe 10.2.6 - it took 0.0665 seconds -
basically instant, can't complain about that.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
Phillips
Sent: Thursday, 9 July 2009
25 matches
Mail list logo
