Re: index-only quals vs. security_barrier views

On Sat, Feb 11, 2012 at 7:16 AM, Jesper Krogh <jesper(at)krogh(dot)cc> wrote:
> Ok, but there are still cases where we don't even need to construct
> a data tuple at all:
>
> 2012-02-11 13:14:01.579 jk=# explain select count(*) from testtable where
> fts @@ to_tsquery('english','test1');
>                                QUERY PLAN
> ---------------------------------------------------------------------------
>  Aggregate  (cost=31.24..31.25 rows=1 width=0)
>   ->  Bitmap Heap Scan on testtable  (cost=16.03..31.23 rows=4 width=0)
>         Recheck Cond: (fts @@ '''test1'''::tsquery)
>         ->  Bitmap Index Scan on ftsid  (cost=0.00..16.03 rows=4 width=0)
>               Index Cond: (fts @@ '''test1'''::tsquery)
> (5 rows)

In that case I believe you DO need the heap tuple. That "Recheck
Cond" there means that the index might be lossy - i.e. return tuples
that don't really match the search condition.

> Another idea sprung into my head, that indices on (ctid,<some mix of
> columns>)
> could actually serve as some kind of "vertical" partitioning of the table.

The ctid of a tuple is its physical position in the table. It makes
no sense to index that. Since it's unique, it makes even less sense
to index that plus other things in the same index.

Does anyone have any comments on the issue raised in my original
email? I would like to get (some version of) his patch committed, but
I would also like to not back ourselves into a corner.

Thanks,

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company