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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: scan key push down to heap [WIP]
Date: 2016-12-01 20:48:48
Message-ID: CA+TgmoYSb17cRWTLY6eTYDJ2t8ixYYSE4b7BYL5sACS3KWWSOg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 30, 2016 at 5:41 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-12-01 20:52:27 Re: Parallel safety of CURRENT_* family
Previous Message Tom Lane 2016-12-01 20:46:15 Re: Parallel safety of CURRENT_* family