From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP patch: distinguish selectivity of < from <= and > from >= |
Date: | 2017-07-04 14:59:10 |
Message-ID: | 2277.1499180350@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> On Tue, Jul 4, 2017 at 9:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> regression=# explain analyze select * from tenk1 where thousand < 10;
>> before:
>> Bitmap Heap Scan on tenk1 (cost=5.14..241.38 rows=110 width=244) (actual time=0.121..0.623 rows=100 loops=1)
>> with patch:
>> Bitmap Heap Scan on tenk1 (cost=5.06..227.42 rows=100 width=244) (actual time=0.054..0.300 rows=100 loops=1)
> It's expected that the estimates will change with this patch. But I am
> wondering why should actual times vary so much. May be that's just
> accidental. Butthe actual timings are consistently lower with the
> patch except the last one
I didn't intend those examples to illustrate anything except row counts,
so I didn't worry about making the timings comparable. Some of the
examples were probably the first query in a session and so would've faced
cache-populating costs the others didn't. Also, the "before" examples
were all done on 9.6 not HEAD.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2017-07-04 15:32:26 | Re: WIP patch: distinguish selectivity of < from <= and > from >= |
Previous Message | AP | 2017-07-04 10:57:28 | pgsql 10: hash indexes testing |