Re: Proposal: scan key push down to heap [WIP]

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Proposal: scan key push down to heap [WIP]
Дата
Msg-id CA+TgmoYSb17cRWTLY6eTYDJ2t8ixYYSE4b7BYL5sACS3KWWSOg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: scan key push down to heap [WIP]  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Wed, Nov 30, 2016 at 5:41 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> 1. As we decided to separate scankey and qual during planning time. So
> I am doing it at create_seqscan_path. My question is currently we
> don't have path node for seqscan, so where should we store scankey ?
> In Path node, or create new SeqScanPath node ?. In attached patch I
> have stored in Path node.

Well, Path should obviously only contain those things that are common
across all kinds of paths, so I would think you'd need to invent
SeqScanPath.

> 2. This is regarding instrumentation information for scan key, after
> my changes currently explain analyze result will look like this.
>
> postgres=# explain (analyze, costs off) select * from lineitem
> where l_shipmode in ('MAIL', 'AIR')
> and l_receiptdate >= date '1994-01-01';
>                                 QUERY PLAN
> --------------------------------------------------------------------------
>  Seq Scan on lineitem (actual time=0.022..12179.946 rows=6238212 loops=1)
>    Scan Key: (l_receiptdate >= '1994-01-01'::date)
>    Filter: (l_shipmode = ANY ('{MAIL,AIR}'::bpchar[]))
>    Rows Removed by Scan Key: 8162088
>    Rows Removed by Filter: 15599495
>  Planning time: 0.182 ms
>  Execution time: 12410.529 ms
>
> My question is, how should we show pushdown filters  ?
> In above plan I am showing as  "Scan Key: ", does this look fine or we
> should name it something else ?

Seems OK to me, but I'm open to better ideas if anybody has any.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parallel safety of CURRENT_* family
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Parallel safety of CURRENT_* family