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 range
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 partition
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 co
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
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 p
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 i
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 feedba
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
th
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 inheritance
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
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
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 not
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 even
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 is
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 du
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,
BTLessEqualStrategyNumber, etc.
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 alone does not tell
enough
abo
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 the operator semantics.
>>
>
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 conversion to text and back to binary form. utils/adt/rangetype
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 binary form. utils/adt/rangetypes.c
> > contains constructor
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 the knowledge that k < 20001 a
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 <= 2 are equivalent for
>>
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
append-only tables in PostgreSQL wher
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 primary key is something like
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:
> Concerning broken partiti
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 i
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 the plans redundant checks.
S
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 checks.
> > > So the only requir
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 checks.
> So the only required action is to update expected file with results.
> Attached please find updated patch.
The last
29 matches
Mail list logo