Re: [HACKERS] Secondary index access optimizations

On 08.10.2018 00:16, David Rowley wrote: On 5 October 2018 at 04:45, Konstantin Knizhnik wrote: Will the following test be enough: -- check that columns for parent table are correctly mapped to child partition of their order doesn't match create table paren (a int, b text) partition by

Re: [HACKERS] Secondary index access optimizations

On 5 October 2018 at 04:45, Konstantin Knizhnik wrote: > Will the following test be enough: > > -- check that columns for parent table are correctly mapped to child > partition of their order doesn't match > create table paren (a int, b text) partition by range(a); > create table child_1

Re: [HACKERS] Secondary index access optimizations

On 04.10.2018 12:19, David Rowley wrote: On 4 October 2018 at 22:11, Konstantin Knizhnik wrote: On 04.10.2018 06:19, David Rowley wrote: Please, can you also add a test which tests this code which has a partition with columns in a different order than it's parent. Having an INT and a TEXT

Re: [HACKERS] Secondary index access optimizations

On 4 October 2018 at 22:11, Konstantin Knizhnik wrote: > On 04.10.2018 06:19, David Rowley wrote: >> Please, can you also add a test which tests this code which has a >> partition with columns in a different order than it's parent. Having >> an INT and a TEXT column is best as if the translations

Re: [HACKERS] Secondary index access optimizations

On 04.10.2018 06:19, David Rowley wrote: On 12 September 2018 at 08:32, Konstantin Knizhnik wrote: Also the patch proposed by you is much simple and does mostly the same. Yes, it is not covering CHECK constraints, I started to look at this and found a problem in regards to varno during the

Re: [HACKERS] Secondary index access optimizations

On 12 September 2018 at 08:32, Konstantin Knizhnik wrote: > Also the patch proposed by you is much simple and does mostly the same. Yes, > it is not covering CHECK constraints, I started to look at this and found a problem in regards to varno during the predicate_implied_by() test. The problem

Re: [HACKERS] Secondary index access optimizations

On Wed, Sep 12, 2018 at 11:43:09AM +0300, Konstantin Knizhnik wrote: > Looks like this qual is considered for choosing optimal path before it is > removed from list of quals in set_append_rel_size. Hm... The latest reviews have not been addressed yet, so I have marked this as returned with

Re: [HACKERS] Secondary index access optimizations

On 12.09.2018 08:14, David Rowley wrote: On 12 September 2018 at 08:32, Konstantin Knizhnik wrote: Also the patch proposed by you is much simple and does mostly the same. Yes, it is not covering CHECK constraints, but as far as partitioning becomes now standard in Postgres, I do not think

Re: [HACKERS] Secondary index access optimizations

On 12 September 2018 at 08:32, Konstantin Knizhnik wrote: > Also the patch proposed by you is much simple and does mostly the same. Yes, > it is not covering CHECK constraints, > but as far as partitioning becomes now standard in Postgres, I do not think > that much people will use old

Re: [HACKERS] Secondary index access optimizations

Hi David, On 11.09.2018 06:49, David Rowley wrote: On 9 July 2018 at 13:26, David Rowley wrote: I started looking over this patch and have a few comments: Hi Konstantin, Wondering, are you going to be submitting an updated patch for this commitfest? If not then I think we can mark this as

Re: [HACKERS] Secondary index access optimizations

On 9 July 2018 at 13:26, David Rowley wrote: > I started looking over this patch and have a few comments: Hi Konstantin, Wondering, are you going to be submitting an updated patch for this commitfest? If not then I think we can mark this as returned with feedback as it's been waiting on author

Re: [HACKERS] Secondary index access optimizations

On 22 March 2018 at 22:38, Konstantin Knizhnik wrote: > Attached please find rebased version of the patch. Hi, I started looking over this patch and have a few comments: I don't think this range type idea is a great one. I don't think it's going to ever perform very well. I also see you're

Re: [HACKERS] Secondary index access optimizations

On 21.03.2018 20:30, Konstantin Knizhnik wrote: On 01.03.2018 23:15, Andres Freund wrote: Hi, This patch seems like quite a good improvement. One thing I've not really looked at but am slightly concerned in passing: Are there cases where we now would do a lot of predicate pruning work

Re: [HACKERS] Secondary index access optimizations

On 01.03.2018 23:15, Andres Freund wrote: Hi, This patch seems like quite a good improvement. One thing I've not really looked at but am slightly concerned in passing: Are there cases where we now would do a lot of predicate pruning work even though the overhead of just evaluating the qual

Re: [HACKERS] Secondary index access optimizations

Hi, This patch seems like quite a good improvement. One thing I've not really looked at but am slightly concerned in passing: Are there cases where we now would do a lot of predicate pruning work even though the overhead of just evaluating the qual is trivial, e.g. because there's only one row

Re: [HACKERS] Secondary index access optimizations

On 29.01.2018 16:24, Konstantin Knizhnik wrote: On 29.01.2018 07:34, Thomas Munro wrote: On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik wrote: On 19.01.2018 16:14, Antonin Houska wrote: you should test the operator B-tree strategy: BTLessStrategyNumber,

Re: [HACKERS] Secondary index access optimizations

On 29.01.2018 07:34, Thomas Munro wrote: On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik wrote: On 19.01.2018 16:14, Antonin Houska wrote: you should test the operator B-tree strategy: BTLessStrategyNumber, BTLessEqualStrategyNumber, etc. The operator string

Re: [HACKERS] Secondary index access optimizations

On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik wrote: > On 19.01.2018 16:14, Antonin Houska wrote: >> you should test the operator B-tree strategy: BTLessStrategyNumber, >> BTLessEqualStrategyNumber, etc. The operator string alone does not tell >> enough >> about

Re: [HACKERS] Secondary index access optimizations

On 19.01.2018 16:14, Antonin Houska wrote: Konstantin Knizhnik wrote: On 11.01.2018 12:34, Antonin Houska wrote: Konstantin Knizhnik wrote: I haven't thought that much about details, so just one comment: you shouldn't need the

Re: [HACKERS] Secondary index access optimizations

Konstantin Knizhnik wrote: > On 11.01.2018 12:34, Antonin Houska wrote: > > Konstantin Knizhnik wrote: > > I haven't thought that much about details, so just one comment: you > > shouldn't > > need the conversion to text and back to

Re: [HACKERS] Secondary index access optimizations

On 11.01.2018 12:34, Antonin Houska wrote: Konstantin Knizhnik wrote: On 09.01.2018 19:48, Antonin Houska wrote: Have you considered using the range types (internally in operator_predicate_proof()) instead of hard-coding operator OIDs? The range types do have

Re: [HACKERS] Secondary index access optimizations

Konstantin Knizhnik wrote: > On 09.01.2018 19:48, Antonin Houska wrote: > >> Have you considered using the range types (internally in >> operator_predicate_proof()) instead of hard-coding operator OIDs? The range >> types do have the knowledge that k < 20001 and k <=

Re: [HACKERS] Secondary index access optimizations

On 09.01.2018 19:48, Antonin Houska wrote: Konstantin Knizhnik wrote: 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

Re: [HACKERS] Secondary index access optimizations

Konstantin Knizhnik wrote: > 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

Re: [HACKERS] Secondary index access optimizations

Greetings, * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote: > On 04.12.2017 19:44, Alvaro Herrera wrote: > >Konstantin Knizhnik wrote: > >> > >>On 30.11.2017 05:16, Michael Paquier wrote: > >>>On Mon, Nov 6, 2017 at 10:13 PM, Konstantin Knizhnik > >>> wrote: >

Re: [HACKERS] Secondary index access optimizations

On Tue, Sep 5, 2017 at 9:10 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > 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

Re: [HACKERS] Secondary index access optimizations

On 04.12.2017 19:44, Alvaro Herrera wrote: Konstantin Knizhnik wrote: On 30.11.2017 05:16, Michael Paquier wrote: On Mon, Nov 6, 2017 at 10:13 PM, Konstantin Knizhnik wrote: Concerning broken partition_join test: it is "expected" failure: my patch removes from

Re: [HACKERS] Secondary index access optimizations

Konstantin Knizhnik wrote: > > > On 30.11.2017 05:16, Michael Paquier wrote: > > On Mon, Nov 6, 2017 at 10:13 PM, Konstantin Knizhnik > > wrote: > > > Concerning broken partition_join test: it is "expected" failure: my patch > > > removes from the plans redundant