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

[HACKERS] Secondary index access optimizations

2017-08-14 Thread Konstantin Knizhnik
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 of secondary index is one of the most critical