ailto:[EMAIL PROTECTED]
Sent: Saturday, August 11, 2007 1:13 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] Speeding up a big BY.EXP select
GEEZ people. Why don't you just "ask the computer" rather than
debating it? And recognize that the U2 platforms differ dependi
But then it wouldn't be as much fun. :-)
-Original Message-
From: Clifton Oliver [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 11, 2007 1:13 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] Speeding up a big BY.EXP select
GEEZ people. Why don't you just "a
GEEZ people. Why don't you just "ask the computer" rather than
debating it? And recognize that the U2 platforms differ depending on
the flavor the account is in.
Us old timers (33 years in MultiValue) need to remember that
everything you think you know is wrong.
On Aug 10, 2007, at 8:41 P
gust 10, 2007 10:32 AM
Subject: RE: [U2] [UV] Speeding up a big BY.EXP select
> I'm not exactly sure how the programming is done on this but from the
> outside it is all relative to how you look at it. Let's take the
> statement:
> SSELECT CUSTOMERS BY NAME BY CITY
> In
-
From: MAJ Programming [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 09, 2007 6:24 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] Speeding up a big BY.EXP select
Jerry: Are you sure. Please make sure that what you are saying is
correct.
The SSELECT statement has traditionally sor
This is looking very promising but probably also needs 'niced up'
dictionaries - our collection of randomly generated dicts doesn't cut it
and I'm getting some fields unnesting and some fields as MV lists per
unnested row.
AA 12345 description of 12345
Description of 9
This is so great!!
"the WHEN-BY.EXP connection was removed a few releases back."
On my 10.0.16 I live under the tyranny of the old regime.
My shorts have thawed . . . Wait, now they've frosted over again:
I'm reading release notes for 10.1 & 10.2 and I don't see anything
about WHEN/BY.E
tie breaker.
Please check again.
Thanks
Mark Johnson
- Original Message -
From: "Jerry Banker" <[EMAIL PROTECTED]>
To:
Sent: Thursday, August 09, 2007 9:39 AM
Subject: RE: [U2] [UV] Speeding up a big BY.EXP select
> The way I see it the first one will take lon
org
Subject: Re: [U2][UV] Speeding up a big BY.EXP select
[EMAIL PROTECTED] wrote:
> Sure - but how long does it take on one of your fast new MFT drives ;-)
Actually, it is exactly the same speed. The temp files that UV uses to
do sorts are accessed linearly so regular arrays work just great
Is there an index on the MV field? If there is, this will speed up an
unconstrained sort on that field.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
[EMAIL PROTECTED] wrote:
Sure - but how long does it take on one of your fast new MFT drives ;-)
Actually, it is exactly the same speed. The temp files that UV uses to
do sorts are accessed linearly so regular arrays work just great. It is
random access and updates that kill rotating disks.
arles" <[EMAIL PROTECTED]>
Reply-To: u2-users@listserver.u2ug.org
To:
Subject: RE: [U2] [UV] Speeding up a big BY.EXP select
Date: Thu, 9 Aug 2007 11:57:15 -0400
Without a doubt:
SELECT BIGFILE BY @ID BY.EXP MV.ATTRIBUTE
-
It has a
Sure - but how long does it take on one of your fast new MFT drives ;-)
Colin Alfke
Calgary Canada
P.S. Give me a call when they work on 64-bit windows servers...
-Original Message-
From: Doug Dumitru
Boydell, Stuart wrote:
> Cool - looks interesting - I'll try that in the morning - tha
In UD (with the proper associations) you can:
>LIST ORDERS CUSTOMER.ID PRODUCT.ID PROD.DESC ORD.QTY TOXML
To get:
This doesn't bother with the sorting or unnesting - which is the whole
point of an XML document, is it not?
Hth
Colin Alfke
Calgary Canada
-Original Message-
Fro
Boydell, Stuart wrote:
Cool - looks interesting - I'll try that in the morning - thanks.
I was curious so I did some testing. Your SSELECT is building very
large temp files in /tmp. My test had 20 MVs of 16 bytes each. I ended
up with almost 2G of temp files. If your MVs are longer (and i
On 8/9/07, Womack, Adrian <[EMAIL PROTECTED]> wrote:
>
> Just one thing to be aware of: SSELECT implies "BY @ID" so the "BY @ID"
> in your statement is redundant.
Adrian, I don't think that is correct (at least for UV). The implied "BY
@ID" sort is always the last sort performed, e.g. "SORT MYFI
Without a doubt:
SELECT BIGFILE BY @ID BY.EXP MV.ATTRIBUTE
-
It has always frosted my shorts that in order for WHEN to kick in, you
need BY.EXP even if you don't care about the sort order.
So, Given that sorting is syntactically necessary,
and Given that you don't really care
The way I see it the first one will take longer than the second,
although it would have to be a large file you are selecting on. The
reason would be that the first one sorts the ID's, redundantly, twice
before it gets to the BY.EXP whereas the second one sorts by the ID only
once.
-Original Me
on't have to be exploded. If it is the second sentence, then you have
to hit it with this kind of query/process.
My 2,000,000 cents
Mark Johnson
- Original Message -
From: "Womack, Adrian" <[EMAIL PROTECTED]>
To:
Sent: Thursday, August 09, 2007 4:15 AM
Subject: RE: [U2]
I did do some small sample testing and found not much difference between
the 2 methods - though on larger sets the BY.EXP seemed marginally
faster than the BY @ID BY.EXP. So barring margins of error due to
machine load I guess that answers most of my question.
The background is extracting data to
Cool - looks interesting - I'll try that in the morning - thanks.
>-Original Message-
> Do you mean you need to explode them, but not sort them?
> If so, use an SQL UNNEST keyword, e.g.
**
This email message and an
My first response would be "try it & see" - and as others have pointed
out, using SELECT rather than SSELECT would have an impact BUT,
then I got to thinking sort order isn't important?
So, my question is "what comes next?" What are you feeding the select
into, that doesn't need informat
Stuart
Do you mean you need to explode them, but not sort them?
If so, use an SQL UNNEST keyword, e.g.
SELECT SURNAME,FORENAME,TITLE_ID,QTY,PRICE FROM UNNEST BOOK_SALES ON
SALE_ITEMS;
You can explode a field to a select list by using the TO SLIST clause, e.g.
SELECT TITLE
Just one thing to be aware of: SSELECT implies "BY @ID" so the "BY @ID"
in your statement is redundant.
To prevent sorting by @ID just use SELECT not SSELECT.
So, if you are using SSELECT then you're already sorting by @ID, so I
doubt you are going to make it any quicker by modifying your SELECT
Add the EXPLAIN keyword to your query and see what the UV query analyzer
says...sometimes useful, mostly not though ;)
Another thing to try is an SQL SELECT, that'll give you a few more grey
hairs...!
Regards
David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
25 matches
Mail list logo
