Re: index-only quals vs. security_barrier views

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: index-only quals vs. security_barrier views
Date: 2012-02-13 14:29:29
Message-ID: CA+TgmoYaQ8piP9mMYtT7bOdwkAscnmFhMbCdhf5ROs3k9XTuow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-02-13 14:29:56 Re: RFC: Making TRUNCATE more "MVCC-safe"
Previous Message Robert Haas 2012-02-13 14:25:00 Re: Optimize referential integrity checks (todo item)