On Tue, Sep 1, 2020 at 9:45 AM Kyotaro Horiguchi
wrote:
> At Mon, 31 Aug 2020 19:10:39 +0900, Etsuro Fujita
> wrote in
> > On Mon, Aug 31, 2020 at 6:20 PM Etsuro Fujita
> > wrote:
> > > * I know your patch is a POC one, but one concern about it (and
> > > Horiguchi-san's patch set) is concurre
Fujita-san, thank you for taking time!
At Mon, 31 Aug 2020 19:10:39 +0900, Etsuro Fujita
wrote in
> On Mon, Aug 31, 2020 at 6:20 PM Etsuro Fujita wrote:
> > * I know your patch is a POC one, but one concern about it (and
> > Horiguchi-san's patch set) is concurrent data fetches by multiple
> >
On Mon, Aug 31, 2020 at 6:20 PM Etsuro Fujita wrote:
> * I know your patch is a POC one, but one concern about it (and
> Horiguchi-san's patch set) is concurrent data fetches by multiple
> foreign scan nodes using the same connection in the case of
> postgres_fdw. Here is an example causing an er
On Thu, Dec 5, 2019 at 1:46 PM Thomas Munro wrote:
> On Thu, Dec 5, 2019 at 4:26 PM Kyotaro Horiguchi
> wrote:
> > There's my pending (somewhat stale) patch, which allows to run local
> > scans while waiting for remote servers.
> >
> > https://www.postgresql.org/message-id/20180515.202945.6933278
On Sun, Dec 1, 2019 at 4:26 AM Bruce Momjian wrote:
> On Sun, Nov 17, 2019 at 09:54:55PM +1300, Thomas Munro wrote:
> > On Sat, Sep 28, 2019 at 4:20 AM Bruce Momjian wrote:
> > > On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote:
> > > > A few years back[1] I experimented with a simple
Hello,
>It is "asynchronous append on async-capable'd postgres-fdw scans". It
>could be called as such in the sense that it is intended to be used
>with sharding.
Yes that's it.
>Did you looked at my benchmarking result upthread? Even it gives
>significant gain even when gathering large numb
Thanks!
At Wed, 29 Jan 2020 14:41:07 +0800, Movead Li wrote in
> >"Parallel scan" at the moment means multiple workers fetch unique
> >blocks from *one* table in an arbitrated manner. In this sense
> >"parallel FDW scan" means multiple local workers fetch unique bundles
> >of tuples from *one
Hello Kyotaro,
>"Parallel scan" at the moment means multiple workers fetch unique
>blocks from *one* table in an arbitrated manner. In this sense
>"parallel FDW scan" means multiple local workers fetch unique bundles
>of tuples from *one* foreign table, which means it is running on a
>si
On Thu, Jan 16, 2020 at 9:41 AM Bruce Momjian wrote:
> On Tue, Jan 14, 2020 at 02:37:48PM +0500, Ahsan Hadi wrote:
> > Summary
> > The patch is pretty good, it works well when there were little data back to
> > the parent node. The patch doesn’t provide parallel FDW scan, it ensures
> > that child
Thank you very much for the testing of the patch, Ahsan!
At Wed, 15 Jan 2020 15:41:04 -0500, Bruce Momjian wrote in
> On Tue, Jan 14, 2020 at 02:37:48PM +0500, Ahsan Hadi wrote:
> > Summary
> > The patch is pretty good, it works well when there were little data back to
> > the parent node. The p
On Tue, Jan 14, 2020 at 02:37:48PM +0500, Ahsan Hadi wrote:
> Summary
> The patch is pretty good, it works well when there were little data back to
> the parent node. The patch doesn’t provide parallel FDW scan, it ensures
> that child nodes can send data to parent in parallel but the parent can o
Hi Hackers,
Sharing the email below from Movead Li, I believe he wanted to share the
benchmarking results as a response to this email thread but it started a
new thread.. Here it is...
"
Hello
I have tested the patch with a partition table with several foreign
partitions living on seperate data
Hello
I have tested the patch with a partition table with several foreign
partitions living on seperate data nodes. The initial testing was done
with a partition table having 3 foreign partitions, test was done with
variety of scale facters. The seonnd test was with fixed data per data
node but nu
Hello.
I think I can say that this patch doesn't slows non-AsyncAppend,
non-postgres_fdw scans.
At Mon, 9 Dec 2019 12:18:44 -0500, Bruce Momjian wrote in
> Certainly any overhead on normal queries would be unacceptable.
I took performance numbers on the current shape of the async execution
pa
On Thu, Dec 5, 2019 at 03:19:50PM -0500, Robert Haas wrote:
> On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian wrote:
> > I agree with Stephen's request. We have been waiting for the executor
> > rewrite for a while, so let's just do something simple and see how it
> > performs.
>
> I'm sympathetic
At Fri, 6 Dec 2019 10:03:44 +1300, Thomas Munro wrote
in
> On Fri, Dec 6, 2019 at 9:20 AM Robert Haas wrote:
> > I don't know whether this patch has that kind of problem. If it
> > doesn't, I would consider that a promising sign.
>
> I'll look into that. If there is a measurable impact, I sus
On Fri, Dec 6, 2019 at 9:20 AM Robert Haas wrote:
>
> On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian wrote:
> > I agree with Stephen's request. We have been waiting for the executor
> > rewrite for a while, so let's just do something simple and see how it
> > performs.
>
> I'm sympathetic to the f
On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian wrote:
> I agree with Stephen's request. We have been waiting for the executor
> rewrite for a while, so let's just do something simple and see how it
> performs.
I'm sympathetic to the frustration here, and I think it would be great
if we could find
On Thu, Dec 5, 2019 at 05:45:24PM +1300, Thomas Munro wrote:
> My patch set (rebased upthread) was extremely primitive, with no new
> planner concepts, and added only a very simple new executor node
> method: ExecReady(). Append used that to try to ask its children if
> they'd like some time to w
On Thu, Dec 5, 2019 at 4:26 PM Kyotaro Horiguchi
wrote:
> There's my pending (somewhat stale) patch, which allows to run local
> scans while waiting for remote servers.
>
> https://www.postgresql.org/message-id/20180515.202945.69332784.horiguchi.kyot...@lab.ntt.co.jp
>
> I (or we) wanted to introd
Hello.
At Sat, 30 Nov 2019 14:26:11 -0500, Bruce Momjian wrote in
> On Sun, Nov 17, 2019 at 09:54:55PM +1300, Thomas Munro wrote:
> > On Sat, Sep 28, 2019 at 4:20 AM Bruce Momjian wrote:
> > > On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote:
> > > > A few years back[1] I experiment
On Sun, Nov 17, 2019 at 09:54:55PM +1300, Thomas Munro wrote:
> On Sat, Sep 28, 2019 at 4:20 AM Bruce Momjian wrote:
> > On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote:
> > > A few years back[1] I experimented with a simple readiness API that
> > > would allow Append to start emittin
On Sat, Sep 28, 2019 at 4:20 AM Bruce Momjian wrote:
> On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote:
> > A few years back[1] I experimented with a simple readiness API that
> > would allow Append to start emitting tuples from whichever Foreign
> > Scan has data available, when work
On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote:
> Hello,
>
> A few years back[1] I experimented with a simple readiness API that
> would allow Append to start emitting tuples from whichever Foreign
> Scan has data available, when working with FDW-based sharding. I used
> that primar
24 matches
Mail list logo
