|
|
Ahhh, so you are looking to cut that 5 years down to 4 months  Clickety[^]
I went to San Juan, Puerto Rico a couple of years ago on a training course for work. It was nice, but windy. I am sure you are going to have a great time. 
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
That certainly doesn't look good!
|
|
|
|
|
You'll be fine. Just don't watch any of the Hostel films)[^] 
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Quote: a backpacking trip to San Juan, Puerto Rico
Better wear your swimsuit. Puerto Rico is an island.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I thought about that after posting, sure would get tired it's a long swim. 
|
|
|
|
|
OK, so every backpack trip seems to have a Kurmudgen ~ One who constantly complains, whines, and is never satisfied about everything, anything, and, often, most everyone, when, truly, there is nothing to complain about.
We, 8 of us, had one such person on a backpack trip once, a 5.6 mile, 2300 vert feet, 6.5+ hour hike in the Sierra Mountains in California.
For the 2 months prior to the trip, every time we would meet up and go over logistics, Tom (fictional names to protect the guilty...) just complained about this, or that, or even about another in the group in a side-comment sort-of-way.
So, I called a special "logistics" meeting. 6 others arrived.
- Where's Tom? others asked.
- He couldn't make it.
- Why not?
- I didn't invite him, because this meeting is *about* him.
- Look, Tom has been complaining these last 6 weeks on every damned thing and nearly every person about the trip. At our next (and last) Logistics Mtg, if he complains more than 3 times about *anything*, trip-related or not, he's asked for what we'll be doing to him.
- Thing is, since he's complaining so much about *nothing*, we're gonna give him something *REAL* to complain about.
- Everyone will go after the meeting to REI and buy a 1 lb deep-sea fishing weight / ball. As we traverse into the climb and rest, you give me the weight, John will "distract" Tom away from his pack, and I'll add the weight to his pack.
Everyone agreed after 30+ minutes of discussing details and the "moral" justification of doing this to Tom. Our code phrase "No Weight," meaning that we would not hike all the way with the weight (no weight), yet we'd note to Tom it was about no "waiting" for anyone at the trailhead; we'll march on without 'em (several car-pools).
Sure enough, Tom complained about 7 different things and 1 person, again side-comment-wise. It was about me.
- OK, everyone, see you at the trailhead. And, remember, "No Weight!"
Everyone nodded in agreement, Tom thinking it was one thing it wasn't. Since he complained about me for no good reason, I bought three 1 lb weights.
Everything worked as planned. On the trip, we stopped 7 times on the hike to "enjoy" scenery and/or rest. Sure enough, Tom complained about this, that and the other, again, all for no reason.
When we stopped, John distracted Tom and I put a new weight deep into his pack, with my 3 lbs of weights the first go in.
About the 4th stop, one "additional" thing Tom stared complaining on was how he seemed to be "not as prepared physically" for the weight of his pack.
We arrived at camp. Tom was the most "wore-out" of all of us. Truth be noted, he was the the most heavy-set of us all. Everyone found a piece of ground to set up camp.
About 35 minutes into setup, Tom yells "WHAT THE HELL?!? Where'd the Hell did these come from?!"
I calmly walked over, several others joining me, and stated:
- None of us know where they came from, Tom.
- But, what we do know is that for the last 8 weeks of planning, you've been complaining about everything, anything, and most everyone, including about me at the last meeting we had.
(The others were nodding in agreement.)
- Well, now you have something *real* to complain about, that being the weight of your back being 'heavier' than you thought.
- If you complain about *anything* or *anyone* these next 3 days, we have far more in store for you (but, really, we didn't). Period. We love ya, Tom, but not the complaining you do. We're here to enjoy the mountains, and enjoy them *with* you and each other.
- Oh, and, by the way, just like we kept reasserting at the meetings, U.S. Forest rules state
"You pack it in, You pack it out!"
===========
Tom was reservedly humble the rest of the trip. Even going out of his way to be helpful and appreciative to others in the group and hikers passing through.
And, yes, we were well-prepared to "assist" Tom, monitoring him the entire hike in, and ready to relieve him of some weight or other help.
On the hike out, Tom concurred he *deserved* to carry the 9 lbs of weight out.
His comment: Well, y'all had the balls to deal with me when I complained. I need to man-up and have the balls to hike out!
===========
What does this hafta do with Five Years to live?
Simple. We helped someone to see and appreciate life and, to this day, some 20 years later, Tom still says "Thank You" [in that quirky ways we friends share such between one-another] for helping him appreciate the life we all have and enjoy together.
modified 14-Jan-14 12:26pm.
|
|
|
|
|
Good story and great lesson.
My son and I recently did a grueling 14mi. hike with 2700 ft. grade in all took 7-1/2 hours and I really had to watch myself because I was really out of shape and my son was "purposely carrying a 40lb pack, he's 23 in the USMC and was training for a triathlon so I felt like I shouldn't say a word.
The only time I really really put up a fuss was when we were about 1-1/2 miles from the trail head and we had to do the last 600ft steep incline and I was really wore out I asked him how he was holding up with the weight he was carrying and he looked fresh as a daisy and I didn't know if I could make the haul but I went ahead and did it and made it OK but I was wore slap out...I'm 64 so I felt like I done pretty good!
|
|
|
|
|
For the life of me, I can't explain this. This isn't intended to be a programming question, more a "nope, don't believe it, even if I'm seeing it" thing.
We host our main app's data in SQL Azure, and we have information in a given table w/ part of the primary key as a datetime (has month-end mutual fund data). One particular function seemed to be taking too long, so we started investigating this afternoon.
If I run a given statement w/ asofdate = '11/30/2013, query takes 20 seconds. Seems slow.
If I run the same statement, changing only asofdate = '10/31/2013', query takes 0.1 seconds. Odd. No significant # of diff recs between those two dates (26,488 for Nov vs. 26,382 for Oct).
So now I'm thinking it's either the way those 11/30 recs were physically stored, or something special about that particular date, until...
If I run the same statement w/ asofdate >= '11/30/2013' (most recent date in db right now), it again takes 0.1 seconds.
Cannot replicate anything close to this in our on-site SQL Server dev dbs.
How the elephant can asofdate >= '11/30/2013' ever be faster than = '11/30/2013'?
modified 10-Jan-14 16:07pm.
|
|
|
|
|
I don't know anything about Azure however if there is some sort of partitioning of data based on dates then this could be quite possible.
Alternatively the database statistics may need refreshing - that can have a big impact if you are talking about tens of millions or hundreds of millions of rows.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Yeah, I definitely thought about partitioning as the cause, but wouldn't I see the same results for equal/greater-than-or-equal to the same date?
|
|
|
|
|
I could make lots of guesses all of which would probably be wrong, one of which might go something like this - what if the database engine prioritises queries that return a higher volume of data(see what I mean?)
First thing I would do is rebuild the indexes and re-run database statistics.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Is asofdate the only parameter in the query? SQL my be picking different execution plans, which result in the different times.
|
|
|
|
|
It's not, and it's also joining another table (the table in question is the child, and it's being linked to the parent), but I've even tried eliminating different parameters, and that didn't make a difference.
However, removing the join, i.e. making the query as simple as possible, did result in a positive difference. So, that does lead me to think about the execution plan, but the data is nearly the same in our dev dbs as production, so that would seem strange that a different execution plan would be generated, though that may be the case.
|
|
|
|
|
Is there a not in directive in the join? If so change it to a not exists as a not in can slow things down tremendously.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
IndifferentDisdain wrote: 11/30/2013
There's your problem - using US-format dates! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ha, yes, however all of our hosting, devs and customers are U.S-based, so that does seem the natural route to go
|
|
|
|
|
IndifferentDisdain wrote: How the elephant can asofdate >= '11/30/2012' ever be faster than = '11/30/2013'?
Did you really mean 11/30/2012?
/ravi
|
|
|
|
|
Meant 11/30/2013 for both; corrected. Thanks.
|
|
|
|
|
OK.
I know I'm not answering your question, but shouldn't the date part of your primary key be in the format "yyyy/mm/dd"? Otherwise, your lexical comparison will be wrong since "12/01/2001" will be greater than "11/01/2012".
/ravi
|
|
|
|
|
No, my dates are formatted as 'mm/dd/yyyy' in my IDE (TOAD for SQL Server).
|
|
|
|
|
Ah. Sorry, I misunderstood. So you have a composite primary key?
/ravi
|
|
|
|
|
Well >= can easily be faster than = because, assuming some sort of binary tree search, as soon as a branch is encountered at the value, everything 'to the right' needs to be included as they are all >=, but with = each node needs to be checked.
Similarly, it may be that 31-10-2013 records are all more easily found because of the tree structure of the indexes (remember its not the way the data is stored but the way the indexes are stored that will make a difference)
If this sort of thing were happening on my local DB I'd be look ing at execution plans, re-building indexes and ensuring suitable indexes exist.
On SQL Azure I don't know what's available.
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
_Maxxx_ wrote: Well >= can easily be faster than = because, assuming some sort of binary
tree search, as soon as a branch is encountered at the value, everything 'to the
right' needs to be included as they are all >=, but with = each node needs to
be checked.
Good answer!!
|
|
|
|
|
For no discernible reason when I heard the lyric:
"You can go sleep at home tonight. If you can get up and walk away"
I thought of Dalek Dave 
!bVagadishnu
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
