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
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 |