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 12:5
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
-
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
U2-U
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
H
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 algor
Hi Ed,
Your test program on unidata 7.1 takes 1137 milliseconds
- 1.1 seconds.
Whilst this is not a totally valid comparison since your test was done on
different hardware (mine was on my laptop), it does show that Unidata almost
certainly cannot be using contiguous strings as it would take
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
strin
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 dictiona
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 memo
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 o
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
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
sign
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 A
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
p
Anyone ever seen this one before? I'm assuming it's a data error,
because this query's been working for 2 years
(it's just a query, no updating being done)
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/lis
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 per
Create an association dictionary and place that on the dictionary items for
@record<2> and @record<3> and RUN_TIME
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Ward
Sent: Tuesday, July 07, 2009 1:27 PM
To: 'U
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
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 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 ma
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
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 look
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 bytes
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 multi
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]
> After indexing, we made a lot more use of the SETINDEX and READFWD
logic
in our programs.
I find this curious / disappointing - is it really the case that unidata
can't take the mix of indexed / unindexed dictionary items and do just
as efficient a job as the code you're writing?
Also, the per
We are on Unidata 7.1 on Sun Solaris
We have used indexing extensively in our database. We have one file with
10 indexes. The file is currently using around 80 gig. (35 dat, 9 idx
and 1 Over parts files). I am not sure how to weigh the update
performance difference these indexes make. But we feel
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 fre
Hi,
A general point on indexes. You should be careful in choosing the data
that you index on. Indexing on a data field where a substantial number of
records in the file have the same value in that field can cause
performance problems.
An extreme example is a field that can contain Y or N. But
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 index
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
Subje
31 matches
Mail list logo
