StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7895142
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2011-10-25T20:02:14.837
FavoriteCount
0
LastActivityDate
2011-10-25T21:41:31.177
LastEditDate
2011-10-25T21:41:31.177
LastEditorUserId
544050
OwnerUserId
1012495
ParentId
7887872
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
Sorry for answering my own question, but at least I have an answer. I try to write it in a such a way that's helpful for others. Since it's a MEMORY table, I excluded I/O problems. Next, the query is a simple (const) select by the primary key, so it cannot be an indexing problem either. The next guess was locking. There are/were some very slow selects in my application on this table. And it can be a problem: slow selects delay updates that delay other selects, so in the end this very simple and fast select can be delayed. I checked the <code>slow query log</code> and found two frequent and slow selects that were using this particular table (and others as well). The cause was a badly formed join on a case: <pre><code>A left join B on case when A.x=1 then B.id=A.id2 when A.x=2 then B.id=A.id3 else B.id=0 end </code></pre> instead of <pre><code>A left join B on B.id = case when A.x=1 then A.id2 when A.x=2 then A.id3 else 0 end </code></pre> Both give the same result, but the latter can use an index of <code>B.id</code>, the former cannot. Once I corrected these queries the performance of the original query was greatly enhanced: <code>5ms</code> instead of <code>500ms</code> on average. And <code>98%</code> faster than average. The moral: <ul> <li>use <code>slow query log</code>, analyse it, and improve slow queries</li> <li>if you encounter inexplicable slow-downs, always check for "crossing" queries that slow down your query by locking the same table</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POSimple constant select on primary key in small MEMORY table very slow
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USPengOne
UserOwnerUserId
1. USCucu
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POSimple constant select on primary key in small MEMORY table very slow
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId
1. COIt's perfectly fine to answer your own question as it may help others in the future. It's also fine and helpful to mark this as the "accepted answer" by clicking the checkmark next to it. This alerts others right away to the fact that this answer worked.
 singulars
 PostPostId
 PO
 UserUserId
 USPengOne
2. COThanks for the feedback. I was not sure about accepting my own answer... I got the message "You can accept your own answer in 2 days", so I'll wait a bit...
 singulars
 PostPostId
 PO
 UserUserId
 USCucu

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.