On 11/29/2013 07:13 PM, Tom Lane wrote: > Andreas Karlsson <andreas@proxel.se> writes: >> I decided to look into how much work implementing the todo item about >> supporting amgettuple in GIN would be, since exclusion constraints on >> GIN would be neat. Robert Haas suggested a solution[1], but to fix it we >> also need to look into why the commit message mentions that it did not >> work anyway with the partial matches. >> ... >> This TIDBitmap becomes lossy if it too many TIDs are added to it, and >> this case is what broke amgettuple for partial matches. > > Right, see > https://urldefense.proofpoint.com/v1/url?u=http://www.postgresql.org/message-id/49AC300F.1050903%40enterprisedb.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=xGch4oNJbpD%2BKPJECmgw4SLBhytSZLBX7UnkZhtNcpw%3D%0A&m=OqhHlGFG81LH1EqJLzTW8HuXdXslGEL%2FPu1f27HxV%2Bs%3D%0A&s=9f3fad064e2845bd2b99c85f684d237fbe96e542081e4b2dc49b1fe51f91f144 > > Note that fixing the potential lossiness in scanning is not the only > roadblock to re-enabling amgettuple. Fast updates also pose problems: > https://urldefense.proofpoint.com/v1/url?u=http://www.postgresql.org/message-id/4974B002.3040202%40sigaev.ru&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=xGch4oNJbpD%2BKPJECmgw4SLBhytSZLBX7UnkZhtNcpw%3D%0A&m=OqhHlGFG81LH1EqJLzTW8HuXdXslGEL%2FPu1f27HxV%2Bs%3D%0A&s=0e08a781fcc17a3d68ce247344a3499a23a9f545b937f254439dadfaf7b9b8ab > > Half of that is basically the same lossiness problem, but the other > half is that we're relying on the bitmap to suppress duplicate reports > of the same TID. It's fairly hard to see how you'd avoid that without > creating other problems. > > Note that Robert's proposed solution is no solution, because it just > puts you right back in the bind of needing guaranteed non-lossy > storage of a TID set that might be too big to fit in memory. You can always call amgetbitmap, and return the tuples from the bitmap one by one. For a lossy result, re-check all tuples on the page. IOW, do a bitmap index + heap scan. You could do that within indexam.c, and present the familiar index_getnext() interface for callers. Or you could modify the exclusion constraint code to do that if amgettuple is not available - Heikki
pgsql-hackers by date:
Соглашаюсь с условиями обработки персональных данных