Hi Thibaut,
On 2019/04/06 1:12, Thibaut wrote:
> Le 25/03/2019 à 01:31, Amit Langote a écrit :
>> On 2019/03/22 17:17, Amit Langote wrote:
>>> I'll add this to July fest to avoid forgetting about this.
>> I'd forgotten to do this, but done today. :)
>>
>> Thanks,
>> Amit
>
> Hello Amit,
>
> Just
Le 25/03/2019 à 01:31, Amit Langote a écrit :
> On 2019/03/22 17:17, Amit Langote wrote:
>> I'll add this to July fest to avoid forgetting about this.
> I'd forgotten to do this, but done today. :)
>
> Thanks,
> Amit
Hello Amit,
Just a quick information that your last patch does not apply on he
On 2019/03/26 0:21, Robert Haas wrote:
> On Wed, Mar 20, 2019 at 12:37 AM Amit Langote
> wrote:
>> That's because get_relation_constraints() no longer (as of PG 11) includes
>> the partition constraint for SELECT queries.
>
> What commit made that change?
That would be 9fdb675fc5d2 (faster parti
On Wed, Mar 20, 2019 at 12:37 AM Amit Langote
wrote:
> That's because get_relation_constraints() no longer (as of PG 11) includes
> the partition constraint for SELECT queries.
What commit made that change?
This sounds to me like maybe it should be an open item.
--
Robert Haas
EnterpriseDB: ht
On 2019/03/22 17:17, Amit Langote wrote:
> I'll add this to July fest to avoid forgetting about this.
I'd forgotten to do this, but done today. :)
Thanks,
Amit
Hi David,
Thanks for checking.
On 2019/03/20 19:41, David Rowley wrote:
> On Wed, 20 Mar 2019 at 17:37, Amit Langote
> wrote:
>> That's because get_relation_constraints() no longer (as of PG 11) includes
>> the partition constraint for SELECT queries. But that's based on an
>> assumption that p
On Wed, 20 Mar 2019 at 17:37, Amit Langote
wrote:
> That's because get_relation_constraints() no longer (as of PG 11) includes
> the partition constraint for SELECT queries. But that's based on an
> assumption that partitions are always accessed via parent, so partition
> pruning would make loadi
