Hello.
> I've gone ahead and marked this as Rejected. The concept of async
> execution of postgres_fdw is certainly still open and a worthwhile goal,
> but this implementation isn't the way to achieve that.
It sounds fair. I'm satisfied that we have agreed that the goal
is worthwhile. I'll show
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm all for improving performance of postgres_fdw and would like to see
> > us support sending queries off to be worked asyncronously, but starting
> > execution on the remote server during ExecInitNode is against the
> > doc
Stephen Frost writes:
> I'm all for improving performance of postgres_fdw and would like to see
> us support sending queries off to be worked asyncronously, but starting
> execution on the remote server during ExecInitNode is against the
> documentated FDW API spec. I discussed exactly this issue
Kyotaro,
* Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote:
> The attached is the fixed patch. It apparently improves the
> performance for the test case shown in the previous mail, in
> which the average tuple length is about 140 bytes.
I'm all for improving performance of postgres_fd
Hello, thank you for looking this but sorry that the last patch
was buggy so that adaptive fetch size did not work.
The attached is the fixed patch. It apparently improves the
performance for the test case shown in the previous mail, in
which the average tuple length is about 140 bytes.
21 Jan 2
I'm trying to compare v5 and v6 in my laptop right now. Apparently my
laptop is quite a bit faster than your machine because the tests complete
in roughly 3.3 seconds.
I added more data and didn't see anything other than noise. (Then again
the queries were dominated by the disk sort so I should
Hello, thank you for the comment. I added experimental adaptive
fetch size feature in this v6 patch.
At Tue, 20 Jan 2015 04:51:13 +, Matt Kelly wrote in
> I think its telling that varying the fetch size doubled the performance,
> even on localhost. If you were to repeat this test across a
I think its telling that varying the fetch size doubled the performance,
even on localhost. If you were to repeat this test across a network, the
performance difference would be far more drastic.
I understand the desire to keep the fetch size small by default, but I
think your results demonstrate
Hello, that's a silly mistake. fetch_seize = 1 in the v4
patch. This v5 patch is fixed at the point.
> But the v4 patch mysteriously accelerates this query, 6.5 seconds.
>
> > =# EXPLAIN (ANALYZE ON, COSTS OFF) SELECT x.a, x.c, y.c
> >FROM ft1 AS x JOIN ft1 AS y on x.a = y.a;
...
> > Exe
I revised the patch so that async scan will be done more
aggressively, and took execution time for two very simple cases.
As the result, simple seq scan gained 5% and hash join of two
foreign tables gained 150%. (2.4 times faster).
While measuring the performance, I noticed that each scan in a
qu
Hello,
> > I'll look into the case after this, but I'd like to send a
> > revised patch at this point.
> Hm. Seems like this patch is not completely baked yet. Horiguchi-san,
> as you are obviously still working on it, would you agree to move it
> to the next CF?
Yes, that's fine with me. Thank y
On Tue, Jan 13, 2015 at 8:46 PM, Kyotaro HORIGUCHI
wrote:
> I'll look into the case after this, but I'd like to send a
> revised patch at this point.
Hm. Seems like this patch is not completely baked yet. Horiguchi-san,
as you are obviously still working on it, would you agree to move it
to the ne
On Tue, Jan 13, 2015 at 6:46 AM, Kyotaro HORIGUCHI
wrote:
>> Is it possible to use the parallel query infrastructure being built by
>> Robert or to do something like parallel seq scan? That will work, not just
>> for Postgres FDW but all the FDWs.
>
> But, I think, from the performance view, every
Hello,
> - The issue of PREPARE is not addressed yet.
...
> > In case of Prepared statements, ExecInit is called at the end of planning,
> > without subsequent execution like the case of EXPLAIN. I see that the patch
> > handles EXPLAIN well, but I didn't see any specific code for PREPARE.
>
> I
Hello. This is a version 3 patch.
- PgFdwConnState is removed
- PgFdwConn is isolated as a separate module.
- State transition was simplicated, I think.
- Comment about multiple scans on a connection is added.
- The issue of PREPARE is not addressed yet.
- It is to show how the new style look
On Fri, Jan 9, 2015 at 2:00 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello, thank you for the comment.
>
> This is the second version of the patch.
>
> - Refactored to make the code simpler and clearer.
> - Added comment about logic outline and struct members.
> - Removed
Hello, thank you for the comment.
This is the second version of the patch.
- Refactored to make the code simpler and clearer.
- Added comment about logic outline and struct members.
- Removed trailig white spaces..
- No additional test yet.
==
> warning: 3 lines add whitespace errors.
Who
Hello, thank you for the comment, Ashutosh.
I'll return after the New Year holidays. Very sorry not
addressing them sooner but then I will have more time on this.
Have a happy holidays.
regards,
=
> Hi Horiguchi-san,
> Here are my comments for the patches together
>
> Sanity
> 1. The patch
Hi Horiguchi-san,
Here are my comments for the patches together
Sanity
1. The patch applies cleanly but has trailing white spaces.
[ashutosh@ubuntu coderoot]git apply
/mnt/hgfs/tmp/0001-Async-exec-of-postgres_fdw.patch
/mnt/hgfs/tmp/0001-Async-exec-of-postgres_fdw.patch:41: trailing whitespace.
Hello, this is the 2nd session of 'intoroducing parallelism using
postgres_fdw'.
The two patch attached are as following,
- 0001-Async-exec-of-postgres_fdw.patch
Main patch, which includes all functions.
- 0002-rename-PGConn-variable.patch
Renaming the variable conn for readability. No funct
20 matches
Mail list logo
