On Thu, Sep 8, 2016 at 2:58 PM, Vladimir Sitnikov
wrote:
> Ildar> Could you please try the patch and tell if it works for you?
>
> I've tested patch6 against recent head. The patch applies with no problems.
>
> The previous case (filter on top of i-o-s) is fixed. Great work.
>
> Here are the test
Ildar> Could you please try the patch and tell if it works for you?
I've tested patch6 against recent head. The patch applies with no problems.
The previous case (filter on top of i-o-s) is fixed. Great work.
Here are the test cases and results:
https://gist.github.com/vlsi/008e18e18b609fcaaec53
Hi Vladimir,
On 05.09.2016 16:38, Ildar Musin wrote:
Hi Vladimir,
On 03.09.2016 19:31, Vladimir Sitnikov wrote:
Ildar>The reason why this doesn't work is that '~~' operator (which is a
Ildar>synonym for 'like') isn't supported by operator class for btree.
Since
Ildar>the only operators support
Hi Tomas,
On 03.09.2016 14:37, Tomas Vondra wrote:
Hi Ildar,
I've looked at this patch again today to do a bit more thorough review,
and I think it's fine. There are a few comments (particularly in the new
code in check_index_only) that need improving, and also a few small
tweaks in the walkers
Hi Vladimir,
On 03.09.2016 19:31, Vladimir Sitnikov wrote:
Ildar>The reason why this doesn't work is that '~~' operator (which is a
Ildar>synonym for 'like') isn't supported by operator class for btree. Since
Ildar>the only operators supported by btree are <, <=, =, >=, >, you can use
Ildar>it w
Ildar>The reason why this doesn't work is that '~~' operator (which is a
Ildar>synonym for 'like') isn't supported by operator class for btree. Since
Ildar>the only operators supported by btree are <, <=, =, >=, >, you can use
Ildar>it with queries like:
Ildar>And in 3rd query 'OFFSET' statement p
Hi Ildar,
I've looked at this patch again today to do a bit more thorough review,
and I think it's fine. There are a few comments (particularly in the new
code in check_index_only) that need improving, and also a few small
tweaks in the walkers.
Attached is a modified v5 patch with the propo
Hi Vladimir,
On 23.08.2016 23:35, Vladimir Sitnikov wrote:
Hi,
I've tried your indexonlypatch5.patch against REL9_6_BETA3.
Here are some results.
TL;DR:
1) <> does not support
index-only scan for index (type, upper(vc) varchar_pattern_ops).
3) <<(... where type=42 offset 0) where upper_vc like
Hi,
I've tried your indexonlypatch5.patch against REL9_6_BETA3.
Here are some results.
TL;DR:
1) <> does not support index-only
scan for index (type, upper(vc) varchar_pattern_ops).
3) <<(... where type=42 offset 0) where upper_vc like '%ABC%'>> does
trigger index-only scan. IOS reduces number of
On Tue, Aug 16, 2016 at 2:43 AM, Alexander Korotkov
wrote:g of pg_operator.oprassociative...
> Another problem is computational complexity of such transformations. AFAIR,
> few patches for making optimizer smarter with expressions were already
> rejected because of this reason.
s/few/many/
> Al
On Tue, Aug 16, 2016 at 9:09 AM, Oleg Bartunov wrote:
> On Tue, Aug 16, 2016 at 1:03 AM, Ildar Musin
> wrote:
> > Hi, hackers!
> >
> > There is a known issue that index only scan (IOS) can only work with
> simple
> > index keys based on single attributes and doesn't work with index
> > expressio
On Tue, Aug 16, 2016 at 1:03 AM, Ildar Musin wrote:
> Hi, hackers!
>
> There is a known issue that index only scan (IOS) can only work with simple
> index keys based on single attributes and doesn't work with index
> expressions. In this patch I propose a solution that adds support of IOS for
> in
On 08/16/2016 12:03 AM, Ildar Musin wrote:
Hi, hackers!
There is a known issue that index only scan (IOS) can only work with
simple index keys based on single attributes and doesn't work with index
expressions. In this patch I propose a solution that adds support of IOS
for index expressions. He
13 matches
Mail list logo
