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') from (logdate < '2017-04-01')
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 Konstantin,
Is there any reason w
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 result of this optimization:
ext
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 filter conditions are removed fro
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 sti
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, b
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=# explain select * from bt where k
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 between 1 and 2 and v
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
---
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
>> --
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
--
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 (cost=0.29..15.63 rows=2 width=8
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 mos
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 of
14 matches
Mail list logo
