Confirming Starbucks “spoof”
Today I read a translated email of “Howard Schultz’s Thank You Letter to Starbucks Customers”. Been bitten many times by lots of hoax in the past, I searched about it.
Urban legend found it as a “spoof”. Those of you, dear readers, that wish to believe that his hands are not bloodstained, can stop reading here.
Its analysis give a link to the original content. I followed the link and end here. The full letter and an update by the writer, stating
However, all the statements I made in that letter about donations, sponsorships, political views etc. – are based on factual Howard Schultz actions and quotes, as 1/2 hour of ‘Googling’ will easily confirm to anyone interested.
We all believe what we choose to believe.
Screenshot here
Jignesh redid MonetDB’s benchmark
Knowing that MonetDB updated TPC-H benchmark result and indicating that postgresql performance is troublesome, he redid the benchmark on his own.
I redid a quick test with the same workload on one of my systems with SF
10 which is about 10GB
(I hope it comes out properly displayed)Jignesh From Monet (8.3T/8.2.9)
..details skipped. Follow the link to see …
All time is in seconds (sub seconds where availabe)
Ratio > 1 means 8.3.3 is slower and <1 means 8.3.3 is fasterMy take on the results:
* I had to tweak the statement of Q1 in order to execute it.
(TPC-H kit does not directly support POSTGRESQL statements)* Timings with 8.3.3 and bit of tuning gives much better time overall
This was expected (Some queries finish in 7% of the time than what
MonetDB reported. From the queries that worked only Q7 & Q21 seem to
have regressed)* However Empty rows results is occuring consistently
(Infact Q11 also returned empty for me while it worked in their test)
Queries: 4,5,6,10,11,12,14,15
(ACTION ITEM: I will start separate threads for each of those queries in
HACKERS alias to figure out the problem since it looks like Functional
problem to me and should be interesting to hackers alias)* Two queries 17,20 looks like will not finish (I let Q17 to run for 18 hrs and yet it had not completed. As for Q20 I killed it as it was approaching
an hour.)
(ACTION ITEM: Not sure whether debugging for these queries will go in
hackers or perform alias but I will start a thread on them too.)* Looks like bit of tuning is required for Q1, Q7, Q9, Q21 to improve their
overall time. Specially understanding if PostgreSQL is missing a more
efficient plan for them.
(ACTION ITEM: I will start separate threads on performance alias to
dig into those queries)I hope to start separate threads for each queries so we can track them
easier. I hope to provide explain analyze outputs for each one of them
and lets see if there are any problems.Feedback welcome on what you want to see for each threads.
Regards,
Jignesh
Many factors affecting postges performance
found here. Maybe I’ll revisit this.
But there are so many variables involved in
database tuning as to make such a claim hard to swallow. For instance
. . .
> fits their system best? I figure (somewhat simplistically) that most
> settings are more related to available memory than anything else, so
. . . your figuring here is indeed simplistic. Every day I see
requests for help from people who have followed the rule of thumb “1/4
of memory for shared_buffers”, except that they’re also running
apache+jakarta, MySQL, and a mail server on the same box. They wonder
why the stock advice is so wrong. It’s wrong because a
general-purpose tool is almost never going to come pre-set for every
possible workload you might want to throw at it. So even “how much
memory” there is on the machine is a question that is harder to answer
than it might seem. Disk layout, data access patterns, even the
filesystem you choose can make significant differences in how the
system performs.
