From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Allow GIN's extractQuery method to signal that nothing can |
Date: | 2007-01-31 15:40:15 |
Message-ID: | 26326.1170258015@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
teodor(at)postgresql(dot)org (Teodor Sigaev) writes:
> Log Message:
> -----------
> Allow GIN's extractQuery method to signal that nothing can satisfy the query.
> In this case extractQuery should returns -1 as nentries. This changes
> prototype of extractQuery method to use int32* instead of uint32* for
> nentries argument.
> Based on that gincostestimate may see two corner cases: nothing will be found
> or seqscan should be used.
This patch contains some pretty ugly coding in gincostestimate that
thinks it must go out of its way to prevent full indexscans. But
(a) it does not work (you cannot positively guarantee a plan will not
be chosen just by setting its cost high) and (b) it is unnecessary.
pg_am.amoptionalkey = false is the right way, and you already have that.
So please remove the klugery in gincostestimate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2007-01-31 16:19:50 | Re: pgsql: Allow GIN's extractQuery method to signal that nothing can |
Previous Message | Teodor Sigaev | 2007-01-31 15:23:28 | pgsql: Update FreeBSD DocBook installation notices |