I've pushed the executor part of this, but mostly not the planner part,
because I didn't think the latter was anywhere near ready for prime
time: the regression test changes it was causing were entirely bogus.
Hi Tom,
Thanks for the commit and the explanation. I'll try to address your
comments
Alexander Kuzmenkov writes:
> On 04.09.2017 15:17, Alexey Chernyshov wrote:
>> make check-world fails on contrib/postgres_fdw because of Subquery Scan on
>> ... Probably, query plan was changed.
> Thanks for testing! This is the same problem as the one in
> 'select_distinct' I mentioned before.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
One thing I have noticed is a trailing whitespace after "bogu
On 04.09.2017 15:17, Alexey Chernyshov wrote:
make check-world fails on contrib/postgres_fdw because of Subquery Scan on ...
Probably, query plan was changed.
Hi Alexey,
Thanks for testing! This is the same problem as the one in
'select_distinct' I mentioned before. I changed the test, the u
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi Alexander,
make check-world fails on contrib/postgres_fdw because of
|Hello everyone,
I made a new patch according to the previous comments. It is simpler
now, only adding a few checks to the bitmap heap scan node. When the
target list for the bitmap heap scan is empty, and there is no filter,
and the bitmap page generated by the index scan is exact, and the
c
On 12.04.2017 12:29, Alexander Korotkov wrote:
That's a cool feature for FTS users! Please, register this patch to
the next commitfest.
I've added this to the 2017-07 commitfest:
https://commitfest.postgresql.org/14/1117/
Also, what is planning overhead of this patch? That's worth
t
On 12.04.2017 17:24, Tom Lane wrote:
TBH, I'm not sure you need to do any of that work. Have you got evidence
that the planner will fail to choose the right plan regardless? I'm
particularly unconvinced that choose_bitmap_and is a critical problem,
because once you're into having to AND multiple
Alexander Kuzmenkov writes:
> With planner, the changes are more complex. Two things must be done
> there. First, when the tlist is empty, we must use a different cost
> function for bitmap heap scan, because the heap access pattern is
> different. Second, choose_bitmap_and() must use a differe
On 12.04.2017 15:04, Tom Lane wrote:
Andrew Gierth writes:
"Alexander" == Alexander Kuzmenkov writes:
Alexander> Structurally, the patch consists of two major parts: a
Alexander> specialized executor node
Why?
It strikes me that the significant fact here is not that we're doing
count(*), b
Andrew Gierth writes:
> "Alexander" == Alexander Kuzmenkov writes:
> Alexander> Structurally, the patch consists of two major parts: a
> Alexander> specialized executor node
> Why?
> It strikes me that the significant fact here is not that we're doing
> count(*), but that we don't need any co
> "Alexander" == Alexander Kuzmenkov writes:
Alexander> Structurally, the patch consists of two major parts: a
Alexander> specialized executor node
Why?
It strikes me that the significant fact here is not that we're doing
count(*), but that we don't need any columns from the bitmap heap s
On Wed, Apr 12, 2017 at 12:40 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Apr 11, 2017 at 8:24 PM, Alexander Kuzmenkov <
> a.kuzmen...@postgrespro.ru> wrote:
>
>> I would like to propose a patch that speeds up the queries of the form
>> 'select
>> count(*) ... where ...',
On Tue, Apr 11, 2017 at 8:24 PM, Alexander Kuzmenkov <
a.kuzmen...@postgrespro.ru> wrote:
> I would like to propose a patch that speeds up the queries of the form
> 'select
> count(*) ... where ...', where the restriction clauses can be satisfied
> by some
> indexes. At the moment, such queries u
Hi,
I would like to propose a patch that speeds up the queries of the form
'select
count(*) ... where ...', where the restriction clauses can be satisfied
by some
indexes. At the moment, such queries use index-only scans followed by
aggregation. Index-only scans are only possible for indexes
15 matches
Mail list logo
