Re: [HACKERS] Secondary index access optimizations

2017-11-06 Thread Konstantin Knizhnik
On 11/06/2017 04:27 AM, Thomas Munro wrote: On Fri, Sep 8, 2017 at 3:58 AM, Konstantin Knizhnik wrote: Updated version of the patch is attached to this mail. Also I added support of date type to operator_predicate_proof to be able to imply (logdate <= '2017-03-31')

Re: [HACKERS] Secondary index access optimizations

2017-11-05 Thread Thomas Munro
On Fri, Sep 8, 2017 at 3:58 AM, Konstantin Knizhnik wrote: > Updated version of the patch is attached to this mail. > Also I added support of date type to operator_predicate_proof to be able to > imply (logdate <= '2017-03-31') from (logdate < '2017-04-01') . Hi

Re: [HACKERS] Secondary index access optimizations

2017-09-07 Thread Konstantin Knizhnik
On 07.09.2017 13:00, Thomas Munro wrote: On Sun, Sep 3, 2017 at 4:34 AM, Konstantin Knizhnik wrote: Thank you for review. I attached new version of the patch with remove_restrictions_implied_by_constraints() function. Concerning failed tests - this is actually

Re: [HACKERS] Secondary index access optimizations

2017-09-07 Thread Thomas Munro
On Sun, Sep 3, 2017 at 4:34 AM, Konstantin Knizhnik wrote: > Thank you for review. > I attached new version of the patch with > remove_restrictions_implied_by_constraints() function. > Concerning failed tests - this is actually result of this optimization: > extra

Re: [HACKERS] Secondary index access optimizations

2017-09-05 Thread Konstantin Knizhnik
On 05.09.2017 04:02, Amit Langote wrote: Like Thomas, I'm not so sure about the whole predtest.c patch. The core logic in operator_predicate_proof() should be able to conclude that, say, k < 21 is implied by k <= 20, which you are trying to address with some special case code. If there is

Re: [HACKERS] Secondary index access optimizations

2017-09-04 Thread Amit Langote
On 2017/09/04 20:46, Konstantin Knizhnik wrote: > On 04.09.2017 12:59, Amit Langote wrote: >> On 2017/09/04 18:19, Konstantin Knizhnik wrote: >>> Concerning your suggestion to merge check_index_predicates() and >>> remove_restrictions_implied_by_constraints() functions: may be it can be >>> done,

Re: [HACKERS] Secondary index access optimizations

2017-09-04 Thread Konstantin Knizhnik
On 04.09.2017 12:59, Amit Langote wrote: Hi Konstantin, On 2017/09/04 18:19, Konstantin Knizhnik wrote: On 04.09.2017 05:38, Amit Langote wrote: On 2017/09/02 12:44, Thomas Munro wrote: On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik wrote: postgres=#

Re: [HACKERS] Secondary index access optimizations

2017-09-04 Thread Amit Langote
Hi Konstantin, On 2017/09/04 18:19, Konstantin Knizhnik wrote: > On 04.09.2017 05:38, Amit Langote wrote: >> On 2017/09/02 12:44, Thomas Munro wrote: >>> On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik >>> wrote: postgres=# explain select * from bt where k

Re: [HACKERS] Secondary index access optimizations

2017-09-04 Thread Konstantin Knizhnik
On 04.09.2017 05:38, Amit Langote wrote: On 2017/09/02 12:44, Thomas Munro wrote: On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik wrote: postgres=# explain select * from bt where k between 1 and 2 and v = 100; QUERY PLAN

Re: [HACKERS] Secondary index access optimizations

2017-09-03 Thread Amit Langote
On 2017/09/02 12:44, Thomas Munro wrote: > On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik > wrote: >> postgres=# explain select * from bt where k between 1 and 2 and v = 100; >> QUERY PLAN >>

Re: [HACKERS] Secondary index access optimizations

2017-09-02 Thread Konstantin Knizhnik
On 09/02/2017 06:44 AM, Thomas Munro wrote: On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik wrote: postgres=# explain select * from bt where k between 1 and 2 and v = 100; QUERY PLAN

Re: [HACKERS] Secondary index access optimizations

2017-09-01 Thread Thomas Munro
On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik wrote: > postgres=# explain select * from bt where k between 1 and 2 and v = 100; > QUERY PLAN > -- > Append

Re: [HACKERS] Secondary index access optimizations

2017-08-16 Thread Konstantin Knizhnik
On 14.08.2017 19:33, Konstantin Knizhnik wrote: On 14.08.2017 12:37, Konstantin Knizhnik wrote: Hi hackers, I am trying to compare different ways of optimizing work with huge append-only tables in PostgreSQL where primary key is something like timestamp and queries are usually accessing

Re: [HACKERS] Secondary index access optimizations

2017-08-14 Thread Konstantin Knizhnik
On 14.08.2017 12:37, Konstantin Knizhnik wrote: Hi hackers, I am trying to compare different ways of optimizing work with huge append-only tables in PostgreSQL where primary key is something like timestamp and queries are usually accessing most recent data using some secondary keys. Size