Are the posted questions getting worse?

Question

Are the posted questions getting worse?

Viewing 15 posts - 9,091 through 9,105 (of 66,712 total)

You must be logged in to reply to this topic. Login to reply

Paul White SSC Guru Points: 150467 More actions · Answer 1

Bob Hovious 24601 (11/7/2009)
Paul,
Are you talking about my jokes, or my serious attempts to offer solutions? Or both? 😀

:laugh: I nearly qualified my previous response to avoid that reply... :laugh:

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Jack Corbett SSC Guru Points: 184394 More actions · Answer 2

Grant Fritchey (11/6/2009)
And yeah, I'm taking a sip from the NDA firehose. The water tastes flipping GREAT! I strongly recommend it. This is some slick stuff.

Great, and just how do I get to the recommended stiff. Some of us don't make the cool kids club like you:-D

Awesome to meet you this past week. Looking forward to seeing you again.

Making plans for 6-8 weeks in New England next summer and hoping to be able to schedule a talk at your user group. No promises, but it is on my to-do list.

Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question

Florian Reischl SSC-Dedicated Points: 37301 More actions · Answer 3

Allister Reid (11/6/2009)
Thought you guys might like this one: http://thedailywtf.com/Articles/Slightly-OverSQLd.aspx

Just found a WTF on a "PostgreSQL Tips and Tricks" blog:

http://blog.gtuhl.com/2009/08/07/postgresql-tips-and-tricks/

Check out "tip" 4...

The Dixie Flatline SSC Guru Points: 53354 More actions · Answer 4

FLO!! You're alive !!!! 😀 😀 😀 😀

Can't stay to talk. Slamming the lid on my PC and heading for the airport. Have a great weekend, all!

__________________________________________________

Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills

Paul White SSC Guru Points: 150467 More actions · Answer 5

Florian Reischl (11/7/2009)
Allister Reid (11/6/2009)
Thought you guys might like this one: http://thedailywtf.com/Articles/Slightly-OverSQLd.aspx
Just found a WTF on a "PostgreSQL Tips and Tricks" blog:
http://blog.gtuhl.com/2009/08/07/postgresql-tips-and-tricks/
Check out "tip" 4...

Ah...that tip shows me exactly where I've been going wrong all these years.

So obvious now. LMAO.

It's 4am so I'm off too - not to catch a plane, to catch some zzzzz.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Jeff Moden SSC Guru Points: 1004366 More actions · Answer 6

Bob Hovious 24601 (11/6/2009)
F_PC = M_Bone*A_Meat
Moden's Law?

Heh... you've just given me an idea for a "fun" article. Thanks, Bob.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Florian Reischl SSC-Dedicated Points: 37301 More actions · Answer 7

Hi Bob

Bob Hovious 24601 (11/7/2009)
FLO!! You're alive !!!! 😀 😀 😀 😀

Sorry for being out of service for a long time. I had to get a little distance between me and SSC (especially The Thread). Not because of any of you guys and gals! I just felt addicted to SSC and spent way too much time here :hehe:.

Can't stay to talk. Slamming the lid on my PC and heading for the airport. Have a great weekend, all!

Bob, have a nice journey and a great weekend!!

Best wishes to all

Flo

Jack Corbett SSC Guru Points: 184394 More actions · Answer 8

Flo,

Glad to see you back. I can relate to the addiction.

Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question

Alvin Ramard SSC-Forever Points: 41190 More actions · Answer 9

Jack Corbett (11/7/2009)
Grant Fritchey (11/6/2009)
And yeah, I'm taking a sip from the NDA firehose. The water tastes flipping GREAT! I strongly recommend it. This is some slick stuff.
Great, and just how do I get to the recommended stiff. Some of us don't make the cool kids club like you:-D
Awesome to meet you this past week. Looking forward to seeing you again.
Making plans for 6-8 weeks in New England next summer and hoping to be able to schedule a talk at your user group. No promises, but it is on my to-do list.

If tips #3 and #4 are correct, then he left out the most important tip:

#13 - Don't use PostgreSQL

Alvin Ramard
Memphis PASS Chapter[/url]

All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]

Matt Miller (4) SSC Guru Points: 124210 More actions · Answer 10

Florian Reischl (11/7/2009)

Just found a WTF on a "PostgreSQL Tips and Tricks" blog:
http://blog.gtuhl.com/2009/08/07/postgresql-tips-and-tricks/
Check out "tip" 4...

Hmm - I just had a brain trust here try to give me the same recommendation... I'll have to ask him for his source next time...:)

(wow - quoted the wrong post - editing to fix...)

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

Florian Reischl SSC-Dedicated Points: 37301 More actions · Answer 11

Alvin Ramard (11/7/2009)
If tips #3 and #4 are correct, then he left out the most important tip:
#13 - Don't use PostgreSQL

:w00t:

I did not notice #3 (which is way more funny than #4)!

gtuhl Newbie Points: 0 More actions · Answer 12

Before everyone gets too excited in here, those tips were written in the context of the following:

hundreds of thousands of active users

hundreds of gigs of data in play for OLTP loads

terabytes of data in play for OLAP loads

thousands of transactions per second at peak load (doing 356 per second right now on a slow Saturday morning, and that's only what got past our distributed cache in front of the DB)

Running on 1 Dell server with PostgreSQL. My individual tables are 30+ million rows in size (for OLTP loads) and growing rapidly every day.

I invite anyone interested to read my response to Florian on the blog. I am a reasonable guy and would love to discuss differences (with this level of DB as the context) in approach.

Florian Reischl SSC-Dedicated Points: 37301 More actions · Answer 13

Hi Joe

I answer here, because I think, it makes no sense to discuss this within your blog. If you prefer this discussion within your blog, just give me a hint (in this thread, by PM or by email). Also send me a PM or mail if you like to continue this discussion under four eyes.

To your #3 (de-normalization):

The explanation within your reply to my comment contained the missing part - in my opinion. It can be a powerful workaround for one special situation to handle one special requirement. However it is always a workaround in a OLTP database. My problem was that you don't point it as "workaround" and other people - probably newbies with databases - read your blog an think they don't need normalization. I saw hundreds of people in my job, here on SSC and on other platforms in the internet who thought they need to de-normalize their database to handle a special requirement. In 99.9% the problem was not a lack of the possible database performance, but a lack of missing experiences. Your blog sounds just too general to me.

To your #4 (joining):

As I wrote on your blog, I have no real clue of PostgreSQL. I just installed it on a VM - with some problems (because of my missing experiences 😛 ). This part of my comment was a real question. I also work with large databases with hundreds of GB and thousands of requests per second on one box. Our tables are up to >750,000,000 rows and we never had problems with JOINs over several tables.

I don't assume that you don't know what you are speaking about. All the other tips make sense to me - as I wrote on your blog. 😉

Greets

Flo

gtuhl Newbie Points: 0 More actions · Answer 14

I certainly was taking no offense and honestly appreciate the comment and dialog. I completely agree with your point that someone just getting started could read those tips and easily take them as blanket statements, I probably need to refine them further. It's a balance of not wanting to stealth edit my original text and providing decent advice for people who hit the page in the future and I probably need to slant more towards the latter.

It is entirely possible the MSSQL Server has a better approach to joining of large tables - it obviously has solid engineering behind it and is used on massive deployments. In PostgreSQL it can be tricky to tweak work_mem (the setting that controls how much RAM an individual join has to play with) per-query and setting it too high with a lot of concurrent users can be big trouble so i've found that rethinking my approach when faced with joining two very large tables pays off big time.

Florian Reischl SSC-Dedicated Points: 37301 More actions · Answer 15

Hi Joe

Your blog showed me some thins I really have to try in my PostgreSQL investigations! Apparently there are some things where SQL Server seems to be better, on the other hand there are features available which are better in PostgreSQL (e.g. the row constructor "INSERT INTO xyz (c1) VALES (1),(2),(3)" is way faster than in SQL Server).

Thanks for your feedback

Flo

PS: You can keep registered to "The Thread" but when you don't want to get email till the end of days you should unsubscribe this thread. It will never die :hehe: