Bucket Priority Queues with large integers for $O(1)$ insert and extract~min?

I recently got into a discussion about Priority Queues when the requirements allow for "best effort" removal (i.e. the removed key may not always be THE very highest priority, but it is relatively close).

After thinking about it a bit I stated "I could probably make it $O(1)$ by using buckets" and approximating the minimum (to bucket size precision). I was politely told that I was wrong. Not taking no for an answer, I later went to Google and found the ample literature on the subject, which seemed to confirm I was wrong :-|

Note that the closely related question, Unique integer priority queue with both $O(1)$ insert and extract-min?, does not allow for approximation, so the answers don't apply to my question.

I was told the standard solution to this problem is to use a queue where keys are appended to the end in $O(1)$ and read from the head in $O(1)$ and which is then periodically sorted in $O(\log N)$ or whatever sorting algorithm you can find.

Assuming 64-bit integers as keys, and a precision of $\pm 127$ (a 56-bit bucket)... Can't you just hold the buckets in a sparse array (so as not to require $2^{56}$ words of memory)... problem solved?

• What do you mean by a "sparse array"? How do you plan to implement that? With a binary search tree or somesuch? Then it's not $O(1)$; it is $O(\log n)$. – D.W. Sep 30 '17 at 1:25
• The sparse array itself would be hash or bucket-based, to provide O(1) access. – Alex R Sep 30 '17 at 5:46
• "Note that the closely related question, Unique integer priority queue with both O(1) insert and extract-min?, does not allow for approximation, so the answers don't apply to my question." -- if a method solves the problem exactly, it also solves them approximately. – Raphael Sep 30 '17 at 5:50
• Hash tables do not provide worst-case O(1) access. – Raphael Sep 30 '17 at 5:51
• It is averaged/amortized for hash is O(1). The exact solution is not O(1). – Alex R Sep 30 '17 at 7:23