Skip site navigation (1) Skip section navigation (2)

Proposal for partial resove issue of GIN fullscan.

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Proposal for partial resove issue of GIN fullscan.
Date: 2007-01-30 17:54:30
Message-ID: 45BF8656.7050703@sigaev.ru (view raw or flat)
Thread:
Lists: pgsql-hackers
Small introduction: GIN index doesn't support full scan of index now because of 
disaster performance. Pointer to each heap tuple will be returned several times. 
  Next, if extractQuery doesn't return anything, GIN generates error 'GIN index 
does not support search with void query'. That is because of different semantic 
meaning of operations: some operation with void query should returns all tuples, 
some nothing.

Now, support function extractQuery has prototype (pseudocode):
Datum *extractQuery( Datum value, uint32 *nentry, StrategyNumber strategy)

Proposal:
Change  extractQuery's prototype to:
Datum *extractQuery( Datum value, int32 *nentry, StrategyNumber strategy)
And add agreement about meaning nentry's value:
nentry > 0  - number of entry to search
nentry = 0  - query requires full scan
nentry < 0  - guarantee that any tuple can't satisfy query

So, if GIN gets nentry < 0 from at least one index quals then 
gingettuple/gingetmulti can do not actual search, just returns false.

Next, modify gincostestimate to call extractQuery to define nentry answer for 
each clause in indexQuals. In case nentry == 0, gincostestimate should return 
disable_cost cost estimate of index search to prevent index usage.

Disadvantage of this proposal: gincostestimate can't work with queries which are 
taken from table or subselect, so proposal doesn't resolve all cases of issue, 
but eliminates most frequent. Void tsquery (from tsearch2) always means empty 
result and fast working of GIN, so, tsearch2's users will not face a error 'GIN 
index does not support search with void query'

Comments, objections, suggestions?


-- 
Teodor Sigaev                                   E-mail: teodor(at)sigaev(dot)ru
                                                    WWW: http://www.sigaev.ru/

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-01-30 17:58:11
Subject: Re: [HACKERS] "May", "can", "might"
Previous:From: Andrej Ricnik-BayDate: 2007-01-30 17:52:20
Subject: Re: "May", "can", "might"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group