I wanted to see the site's top sponsors - users that have paid bounties on questions that they didn't own.

I started off with a bounty-related existing query, selected the details into a subquery, and then grouped by sponsor and ended up with this query, which no longer has anything in common with the query I started off with:

select Sponsor,
       round(sum(cast(BountyClose as float))/(SponsorRep + sum(cast(BountyOpen as float)))*100,2) PctSponsorRep,
       count(*) Bounties,
       sum(BountyOpen)/count(*) AvgBountyPaid,
       sum(BountyOpen) BountyPaid, 
       sum(BountyClose) BountyAwarded,
       avg(cast(DaysOpen as float)) AvgDaysOpen,
       max(BountyCloseDate) LastBountyClosed
from (
       u.DisplayName Sponsor,
       u.Reputation SponsorRep,
       bo.BountyAmount BountyOpen,
       datediff(day, bo.CreationDate, bc.CreationDate) DaysOpen,
       bc.BountyAmount BountyClose,
       bc.CreationDate BountyCloseDate
from Posts q 
  inner join Votes bo on q.Id = bo.PostId 
                     and q.PostTypeId = 1 -- Questions
                     and bo.VoteTypeId = 8 -- BountyOpen
  inner join Users op on q.OwnerUserId = op.Id
  left join Posts a on a.ParentId = q.Id
                     and a.PostTypeId = 2 -- Answers
  left join Votes bc on a.Id = bc.PostId
                     and bc.VoteTypeId = 9 -- BountyClose
  inner join Users u on bo.UserId = u.Id -- bounty owner
where q.ClosedDate is null
  and bc.BountyAmount is not null
  and op.Id != u.Id
  ) subquery
group by Sponsor, SponsorRep
order by
  sum(BountyClose) desc,
  max(BountyCloseDate) desc

Is there anything else I could have done better?

  • \$\begingroup\$ Returns 10 rows in < 1 ms. \$\endgroup\$ Jan 19 '14 at 22:59
  • 3
    \$\begingroup\$ 10 rows returned in 1 ms (cached) :) \$\endgroup\$ Jan 19 '14 at 23:26
  • \$\begingroup\$ @DavidHarkness good catch. It's more like 55 ms, with 41% x2 (82%) being spent doing a Clustered Index Scan on [Votes].[UIX_Votes_Id]. Does it get any better? \$\endgroup\$ Jan 20 '14 at 1:00

I have looked at this query/report, and from the beginning I figured it must be missing something. I looked through the SQL, and can't identify it off-hand, so I figured I would build my own query, and see how they compare. The results I got are very different... :(

Edit: Found the problem

You cannot chain two outer joins.... Consider the query for the missing Quentin votes:

We know from the alternate query, and from Quentin's profile, that he offered a 150 bounty. This 150 does not show up on your query.

Here is a base query that matches your query and it should show this bounty.

it does not. But, if we convert the final outer-joins on alias a and alias bc to an equi-join, and make it a with statement, it all of a sudden works....

The reason is because we need the two outer joins, and the first one succeeds. The first one gets answers to the question (there may not be answers, so we need the outer join). The second outer-join looks for bounty-votes, and the bounty may not be awarded.

I am not sure why this is not working, could be a SQLServer bug?

Second update This issue also accounts for the missing 2 bounties from 200_success... because they are on questions which have answers, but the answers were not awarded the bounty.

This also explains why some offered-but-not-awarded bounties are working, because they were on questions with no answers.

Alternate query here

I have put together this report BountifulII. Obviously, there could be problems with my report too (offer it as a question? - Week-end challenge?).

Note that my report has a couple of odd --firewall fix comments in it, see this MSO Question for the reason... ;-)

My report does a more general process of calculating who offered bounties, and who was awarded bounties. It separates out awarded-bounties to those awarded to their own questions, and those awarded to any question). In the final report it lists the Promotions and PromotedAmount. These values should match with the values in your reports.... but they do not.

here is the revised SQL:

WITH Bounties AS (
       UserID AS UserID,
       0 AS GetCount,
       0 AS GetAmount,
       COUNT(BountyAmount) AS GiveCount,
       SUM(BountyAmount) AS GiveAmount,
       SUM(case when Posts.OwnerUserId = Votes.UserId then 1 else 0 end) AS SelfCount,
       SUM(case when Posts.OwnerUserId = Votes.UserId then BountyAmount else 0 end) AS SelfAmount
    FROM Votes,
    WHERE Votes.PostId = Posts.Id
      AND VoteTypeId = 8
    GROUP --firewall fix
    BY UserID
       Posts.OwnerUserID AS UserID,
       COUNT(BountyAmount) AS GetCount,
       SUM(BountyAmount) AS GetAmount,
       0 AS GiveCount,
       0 AS GiveAmount,
       0 AS SelfCount,
       0 AS SelfAmount
    FROM Votes,
    WHERE Votes.PostId = Posts.ID
      AND VoteTypeId = 9
    GROUP --firewall fix
    BY Posts.OwnerUserID

SELECT UserID AS [User Link],
       SUM(GiveCount - SelfCount) AS Pomotions,
       SUM(GiveAmount - SelfAmount) AS PromotedAmount,
       SUM(GetCount) AS GetCount,
       SUM(GetAmount) AS GetAmount,
       SUM(GiveCount) AS GiveCount,
       SUM(GiveAmount) AS GiveAmount,
       SUM(SelfCount) AS SelfCount,
       SUM(SelfAmount) AS SelfAmount,
       SUM(GiveCount + GetCount) AS EventCount,
       SUM(GetAmount - GiveAmount) AS NetBenefit
FROM Bounties
GROUP -- firewall fix
ORDER BY PromotedAmount DESC, EventCount DESC, NetBenefit DESC

You don't need the op join on Users since you can compare the user IDs in the question directly. Remove that join and in the where clause replace

and op.Id != u.Id


and q.OwnerUserId != bo.UserId

or move this to the first join on Votes.


I would change some things.


inner join Votes bo on q.Id = bo.PostId 
                     and q.PostTypeId = 1 -- Questions
                     and bo.VoteTypeId = 8 -- BountyOpen

kind of stuff needs to go in the where statement. The join on the ID's is ok because that is how the table relates, but the other two and situations are for filtering the results. That should be in the where statement.

Inside the where statement you have

AND op.ID <> u.Id  

that should be in a join, more specifically a FULL OUTER JOIN or maybe better a LEFT OUTER JOIN (LEFT JOIN) .


The reason that I say this last one is because I have sort of done a little bit of research.

I have seen several questions where they had a <> in the where clause, and they were asking about performance.

Turns out that the way that SQL works a <> or a NOT IN clause in the where statement slows down the query, and it is better to try and OUTER JOIN or LEFT JOIN on that column where possible.

I mention this more in my answer.

In the answer I mention a Stack Overflow answer to this question.

This may or may not be usable in your query, but it is something nice to know.

  • \$\begingroup\$ I wonder, readability-wise, if it's best to filter q and a in the WHERE clause. q is Posts, so is a; then being filtered as soon as they're encountered makes it clear that q only contains questions and that a only contains answers. I'd like to read more about ON-clause filtering; is it ever appropriate? \$\endgroup\$ Jan 19 '14 at 23:51
  • \$\begingroup\$ I don't know if it is appropriate or not. it doesn't look right to me. I would do it both ways and see what the performance difference is. you should see if you can do an Explain on the SEDE \$\endgroup\$
    – Malachi
    Jan 20 '14 at 0:18
  • 1
    \$\begingroup\$ If it makes any difference, MySQL simply moves everything in the joins to the where clause. \$\endgroup\$ Jan 20 '14 at 1:07
  • 1
    \$\begingroup\$ For the record, not that it matters in this query… conditions in the WHERE clause are not exactly the same as conditions in the JOIN ON clause. You can use a JOIN ON condition to cause it to join NULL to NULL, for example; that's not possible in the WHERE clause. \$\endgroup\$ Jan 20 '14 at 4:39
  • 1
    \$\begingroup\$ @200_success, I just looked at this comment stream again, you are right that the two conditions are different, that is what I was saying, OP has conditions that are visibly where conditions and not ON conditions. \$\endgroup\$
    – Malachi
    Jan 21 '14 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.