(2019/01/21 17:21), Amit Langote wrote:
On 2019/01/21 17:17, Etsuro Fujita wrote:
(2019/01/19 21:17), Amit Langote wrote:
On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita
wrote:
I updated the patch as such and rebased it to the latest HEAD. I also
added the commit message. Attached is an upd
On 2019/01/21 17:17, Etsuro Fujita wrote:
> (2019/01/19 21:17), Amit Langote wrote:
>> On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita
>> wrote:
>>> I updated the patch as such and rebased it to the latest HEAD. I also
>>> added the commit message. Attached is an updated patch. Does that make
>>
(2019/01/19 21:17), Amit Langote wrote:
On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita
wrote:
I updated the patch as such and rebased it to the latest HEAD. I also
added the commit message. Attached is an updated patch. Does that make
sense? If there are no objections, I'll push that patch
On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita
wrote:
> I updated the patch as such and rebased it to the latest HEAD. I also
> added the commit message. Attached is an updated patch. Does that make
> sense? If there are no objections, I'll push that patch early next week.
Thank you. Looks go
(2019/01/16 14:45), Etsuro Fujita wrote:
(2019/01/15 11:42), Amit Langote wrote:
On 2019/01/11 21:50, Etsuro Fujita wrote:
(2019/01/10 10:41), Amit Langote wrote:
That's a loaded meaning and abusing it to mean something else can be
challenged, but we can live with that if properly documented.
(2019/01/16 15:21), Ashutosh Bapat wrote:
On Wed, Jan 16, 2019 at 11:22 AM Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2019/01/15 13:29), Ashutosh Bapat wrote:
> I think, there's something better possible. Two partitioned relations
> won't use partition-wise join, if
Hi Ashutosh,
(2019/01/15 13:29), Ashutosh Bapat wrote:
I think, there's something better possible. Two partitioned relations
won't use partition-wise join, if their partition schemes do not match.
Partitioned relations with same partitioning scheme share
PartitionScheme pointer. PartitionScheme
(2019/01/15 11:42), Amit Langote wrote:
On 2019/01/11 21:50, Etsuro Fujita wrote:
(2019/01/10 10:41), Amit Langote wrote:
That's a loaded meaning and abusing it to mean something else can be
challenged, but we can live with that if properly documented.
Speaking of
which:
/* used by part
Amit-san,
(2019/01/15 10:46), Amit Langote wrote:
On 2019/01/11 20:04, Etsuro Fujita wrote:
(2019/01/11 13:46), Amit Langote wrote:
However, what you proposed here as-is would
not keep that behavior, because rel->part_scheme is created for those
tables as well
(even though there would be
I think, there's something better possible. Two partitioned relations won't
use partition-wise join, if their partition schemes do not match.
Partitioned relations with same partitioning scheme share PartitionScheme
pointer. PartitionScheme structure should get an extra counter, maintaining
a coun
Fujita-san,
On 2019/01/11 21:50, Etsuro Fujita wrote:
>>> (2019/01/10 10:41), Amit Langote wrote:
That's a loaded meaning and abusing it to mean something else can be
challenged, but we can live with that if properly documented.
Speaking of
which:
/* used by pa
On 2019/01/15 10:46, Amit Langote wrote:
> On 2019/01/11 20:04, Etsuro Fujita wrote:
>> One thing I intended in that commit was to set the flag to false for
>> partitioned tables contained in inheritance trees where the top parent is
>> a UNION ALL subquery, because we don't consider PWJ for those
Fujita-san,
On 2019/01/11 20:04, Etsuro Fujita wrote:
> (2019/01/11 13:46), Amit Langote wrote:
>> On 2019/01/10 15:07, Etsuro Fujita wrote:
>>> (The name of the flag isn't
>>> good? If so, that would be my fault because I named that flag.)
>>
>> If it's really just to store the fact that the rel
(2019/01/11 13:46), Amit Langote wrote:
On 2019/01/10 15:07, Etsuro Fujita wrote:
(2019/01/10 10:41), Amit Langote wrote:
That's a loaded meaning and abusing it to mean something else can be
challenged, but we can live with that if properly documented. Speaking of
which:
/* used by part
(2019/01/11 13:49), Amit Langote wrote:
On 2019/01/11 11:21, Etsuro Fujita wrote:
(2019/01/10 21:23), Amit Langote wrote:
On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
wrote:
Though this will solve a problem for performance when partition-wise
join is not possible, we still have the same p
(2019/01/11 13:46), Amit Langote wrote:
On 2019/01/10 15:07, Etsuro Fujita wrote:
(The name of the flag isn't
good? If so, that would be my fault because I named that flag.)
If it's really just to store the fact that the relation's targetlist
contains expressions that partitionwise join curre
On 2019/01/11 11:21, Etsuro Fujita wrote:
> (2019/01/10 21:23), Amit Langote wrote:
>> On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
>> wrote:
>>> Though this will solve a problem for performance when partition-wise
>>> join is not possible, we still have the same problem when
>>> partition-wise
Fujita-san,
On 2019/01/10 15:07, Etsuro Fujita wrote:
> Amit-san,
>
> (2019/01/10 10:41), Amit Langote wrote:
>> On 2019/01/09 20:20, Etsuro Fujita wrote:
>>> I like your patch in general. I think one way to address Ashutosh's
>>> concerns would be to use the consider_partitionwise_join flag: or
(2019/01/10 21:23), Amit Langote wrote:
On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
wrote:
Though this will solve a problem for performance when partition-wise join is
not possible, we still have the same problem when partition-wise join is
possible. And that problem really happens becaus
On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
wrote:
> Though this will solve a problem for performance when partition-wise join is
> not possible, we still have the same problem when partition-wise join is
> possible. And that problem really happens because our inheritance mechanism
> require
On Thu, Jan 10, 2019 at 7:12 AM Amit Langote
wrote:
> Fujita-san,
>
> On 2019/01/09 20:20, Etsuro Fujita wrote:
> > (2019/01/09 9:30), Amit Langote wrote:
> >> So, while the patch at [1] can take care of this issue as I also
> mentioned
> >> upthread, I was trying to come up with a solution that
Amit-san,
(2019/01/10 10:41), Amit Langote wrote:
On 2019/01/09 20:20, Etsuro Fujita wrote:
I like your patch in general. I think one way to address Ashutosh's
concerns would be to use the consider_partitionwise_join flag: originally,
that was introduced for partitioned relations to show that
Fujita-san,
On 2019/01/09 20:20, Etsuro Fujita wrote:
> (2019/01/09 9:30), Amit Langote wrote:
>> So, while the patch at [1] can take care of this issue as I also mentioned
>> upthread, I was trying to come up with a solution that can be back-patched
>> to PG 11. The patch I posted above is one s
Amit-san,
(2019/01/09 9:30), Amit Langote wrote:
(sorry about the repeated email, but my previous attempt failed due to
trying to send to the -hackers and -performance lists at the same time, so
trying again after removing -performance)
Thanks! (Actually, I also failed to send my post to thos
Fujita-san,
(sorry about the repeated email, but my previous attempt failed due to
trying to send to the -hackers and -performance lists at the same time, so
trying again after removing -performance)
On 2019/01/08 20:07, Etsuro Fujita wrote:
> (2018/12/07 20:14), Ashutosh Bapat wrote:
>> On Fri,
On Fri, Dec 7, 2018 at 11:13 AM Ashutosh Bapat
wrote:
>
>
>
>>
>>
>> Robert, Ashutosh, any comments on this? I'm unfamiliar with the
>> partitionwise join code.
>>
>
> As the comment says it has to do with the equivalence classes being used
> during merge append. EC's are used to create pathkeys
On Thu, Dec 6, 2018 at 1:27 PM Alvaro Herrera
wrote:
> On 2018-Dec-06, Amit Langote wrote:
>
> > The partitionwise join related
> > changes in PG 11 moved the add_child_rel_equivalences call in
> > set_append_rel_size such that child EC members would be added even before
> > checking if the child
On 2018-Dec-06, Amit Langote wrote:
> The partitionwise join related
> changes in PG 11 moved the add_child_rel_equivalences call in
> set_append_rel_size such that child EC members would be added even before
> checking if the child rel is dummy, but for a reason named in the comment
> above the c
On 2018-Dec-06, Amit Langote wrote:
Hi
> [ Parallel SeqScan on precio_126 to precio_998 ]
>
> > -> Parallel Seq Scan on precio_999 p_874
> > (cost=0.00..27.50 rows=1 width=16)
> >Filter: ((fecha >= '1990-05-06
> > 00:00:00'::timestamp without
Hi,
(Re-sending after adding -hackers, sorry for the noise to those who would
receive this twice)
On 2018/12/05 6:55, Alvaro Herrera wrote:
> I noticed another interesting thing, which is that if I modify the query
> to actually reference some partition that I do have (as opposed to the
> above,
On 2018/12/06 11:14, Amit Langote wrote:
> I ran the original unmodified query at [1] (the one that produces an empty
> plan due to all children being pruned) against the server built with
> patches I posted on the "speeding up planning with partitions" [2] thread
> and it finished in a jiffy.
For
Hi,
On 2018/12/05 6:55, Alvaro Herrera wrote:
> On 2018-Dec-04, Alvaro Herrera wrote:
>
>> CREATE TABLE precio(fecha timestamp, pluid int, loccd int, plusalesprice
>> int) PARTITION BY RANGE (fecha);
>> SELECT format('CREATE TABLE public.precio_%s PARTITION OF public.precio
>> (PRIMARY KEY (fe
32 matches
Mail list logo
