On Mon, Apr 10, 2023 at 11:33 AM Michael Paquier wrote:
> On Sat, Apr 08, 2023 at 02:19:54PM -0400, Melanie Plageman wrote:
> > Another worker attached to the batch barrier, saw that it was in
> > PHJ_BATCH_SCAN, marked it done and detached. This is fine.
> > BarrierArriveAndDetachExceptLast() is
On Sat, Apr 08, 2023 at 02:19:54PM -0400, Melanie Plageman wrote:
> Another worker attached to the batch barrier, saw that it was in
> PHJ_BATCH_SCAN, marked it done and detached. This is fine.
> BarrierArriveAndDetachExceptLast() is meant to ensure no one waits
> (deadlock hazard) and that at
On Sat, Apr 8, 2023 at 1:30 PM Melanie Plageman
wrote:
>
> On Sat, Apr 8, 2023 at 12:33 PM Tom Lane wrote:
> >
> > Thomas Munro writes:
> > > I committed the main patch.
> >
> > BTW, it was easy to miss in all the buildfarm noise from
> > last-possible-minute patches, but chimaera just showed
Melanie Plageman writes:
> Having not done much debugging on buildfarm animals before, I don't
> suppose there is any way to get access to the core itself? I'd like to
> see how many participants the batch barrier had at the time of the
> assertion failure. I assume it was 2, but I just wanted to
On Sat, Apr 8, 2023 at 12:33 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > I committed the main patch.
>
> BTW, it was easy to miss in all the buildfarm noise from
> last-possible-minute patches, but chimaera just showed something
> that looks like a bug in this code [1]:
>
> 2023-04-08
Thomas Munro writes:
> I committed the main patch.
BTW, it was easy to miss in all the buildfarm noise from
last-possible-minute patches, but chimaera just showed something
that looks like a bug in this code [1]:
2023-04-08 12:25:28.709 UTC [18027:321] pg_regress/join_hash LOG: statement:
On Wed, Apr 5, 2023 at 7:37 AM Tom Lane wrote:
> The comment is no longer in sync with the code: this if-test used to
> reject JOIN_FULL and JOIN_RIGHT, and no longer does so, but the comment
> still claims it should. Shouldn't we drop the sentence beginning
> "Similarly"? (I see that there's
Thomas Munro writes:
> I committed the main patch.
This left the following code in hash_inner_and_outer (joinpath.c):
/*
* If the joinrel is parallel-safe, we may be able to consider a
* partial hash join. However, we can't handle JOIN_UNIQUE_OUTER,
* because
And, if so, do we need to consider the estimated
number of unmatched tuples to be emitted?
> Are the tests enough?
So, the tests currently in the patch set cover the unmatched tuple scan
phase for single batch parallel full hash join. I've attached the
dumbest possible addition to that which a
On Sun, Mar 26, 2023 at 9:52 AM Melanie Plageman
wrote:
> I have some very minor pieces of feedback, mainly about extraneous
> commas that made me uncomfortable ;)
Offensive punctuation removed.
> > discussion). Therefore FULL JOIN inhibited page-based parallelism,
> > as the other join
On Sat, Mar 25, 2023 at 09:21:34AM +1300, Thomas Munro wrote:
> * reuse the same umatched_scan_{chunk,idx} variables as above
> * rename the list of chunks to scan to work_queue
> * fix race/memory leak if we see PHJ_BATCH_SCAN when we attach (it
> wasn't OK to just fall through)
ah, good
Here is a rebased and lightly hacked-upon version that I'm testing.
0001-Scan-for-unmatched-hash-join-tuples-in-memory-order.patch
* this change can stand on its own, separately from any PHJ changes
* renamed hashtable->current_chunk[_idx] to unmatched_scan_{chunk,idx}
* introduced a local
On Thu, Nov 17, 2022 at 5:22 PM Ian Lawrence Barwick wrote:
> This patch is marked as "Waiting for Committer" in the current commitfest [1]
> with yourself as committer; do you have any plans to move ahead with this?
Yeah, sorry for lack of progress. Aiming to get this in shortly.
2022年4月8日(金) 20:30 Thomas Munro :
>
> On Wed, Jan 12, 2022 at 10:30 AM Melanie Plageman
> wrote:
> > On Fri, Nov 26, 2021 at 3:11 PM Thomas Munro wrote:
> > > #3 0x009cf57e in ExceptionalCondition (conditionName=0x29cae8
> > > "BarrierParticipants(>shared->batch_barrier) == 1",
> > >
On Wed, Jan 12, 2022 at 10:30 AM Melanie Plageman
wrote:
> On Fri, Nov 26, 2021 at 3:11 PM Thomas Munro wrote:
> > #3 0x009cf57e in ExceptionalCondition (conditionName=0x29cae8
> > "BarrierParticipants(>shared->batch_barrier) == 1",
> > errorType=, fileName=0x2ae561 "nodeHash.c",
> >
On Fri, Nov 26, 2021 at 3:11 PM Thomas Munro wrote:
>
> On Sun, Nov 21, 2021 at 4:48 PM Justin Pryzby wrote:
> > On Wed, Nov 17, 2021 at 01:45:06PM -0500, Melanie Plageman wrote:
> > > Yes, this looks like that issue.
> > >
> > > I've attached a v8 set with the fix I suggested in [1] included.
>
On Sun, Nov 21, 2021 at 4:48 PM Justin Pryzby wrote:
> On Wed, Nov 17, 2021 at 01:45:06PM -0500, Melanie Plageman wrote:
> > Yes, this looks like that issue.
> >
> > I've attached a v8 set with the fix I suggested in [1] included.
> > (I added it to 0001).
>
> This is still crashing :(
>
On Wed, Nov 17, 2021 at 01:45:06PM -0500, Melanie Plageman wrote:
> On Sat, Nov 6, 2021 at 11:04 PM Justin Pryzby wrote:
> >
> > > Rebased patches attached. I will change status back to "Ready for
> > > Committer"
> >
> > The CI showed a crash on freebsd, which I reproduced.
> >
small mistake in v8.
v9 attached.
- Melanie
v9-0002-Improve-the-naming-of-Parallel-Hash-Join-phases.patch
Description: Binary data
v9-0003-Parallel-Hash-Full-Right-Outer-Join.patch
Description: Binary data
v9-0001-Fix-race-condition-in-parallel-hash-join-batch-cl.patch
Description: Binary
On Sat, Nov 6, 2021 at 11:04 PM Justin Pryzby wrote:
>
> > Rebased patches attached. I will change status back to "Ready for Committer"
>
> The CI showed a crash on freebsd, which I reproduced.
> https://cirrus-ci.com/task/5203060415791104
>
> The crash is evidenced in 0001 - but only ~15% of the
> Rebased patches attached. I will change status back to "Ready for Committer"
The CI showed a crash on freebsd, which I reproduced.
https://cirrus-ci.com/task/5203060415791104
The crash is evidenced in 0001 - but only ~15% of the time.
I think it's the same thing which was committed and then
On Tue, Sep 21, 2021 at 9:29 AM Jaime Casanova
wrote:
> Do you intend to commit 0001 soon? Specially if this apply to 14 should
> be committed in the next days.
Thanks for the reminder. Yes, I'm looking at this now, and looking
into the crash of this patch set on CI:
On Fri, Jul 30, 2021 at 04:34:34PM -0400, Melanie Plageman wrote:
> On Sat, Jul 10, 2021 at 9:13 AM vignesh C wrote:
> >
> > On Mon, May 31, 2021 at 10:47 AM Greg Nancarrow wrote:
> > >
> > > On Sat, Mar 6, 2021 at 12:31 PM Thomas Munro
> > > wrote:
> > > >
> > > > On Tue, Mar 2, 2021 at 11:27
On Sat, Jul 10, 2021 at 9:13 AM vignesh C wrote:
>
> On Mon, May 31, 2021 at 10:47 AM Greg Nancarrow wrote:
> >
> > On Sat, Mar 6, 2021 at 12:31 PM Thomas Munro wrote:
> > >
> > > On Tue, Mar 2, 2021 at 11:27 PM Thomas Munro
> > > wrote:
> > > > On Fri, Feb 12, 2021 at 11:02 AM Melanie
On Mon, May 31, 2021 at 10:47 AM Greg Nancarrow wrote:
>
> On Sat, Mar 6, 2021 at 12:31 PM Thomas Munro wrote:
> >
> > On Tue, Mar 2, 2021 at 11:27 PM Thomas Munro wrote:
> > > On Fri, Feb 12, 2021 at 11:02 AM Melanie Plageman
> > > wrote:
> > > > I just attached the diff.
> > >
> > > Squashed
On Sat, Mar 6, 2021 at 12:31 PM Thomas Munro wrote:
>
> On Tue, Mar 2, 2021 at 11:27 PM Thomas Munro wrote:
> > On Fri, Feb 12, 2021 at 11:02 AM Melanie Plageman
> > wrote:
> > > I just attached the diff.
> >
> > Squashed into one patch for the cfbot to chew on, with a few minor
> > adjustments
On Tue, Apr 6, 2021 at 11:59 AM Melanie Plageman
wrote:
> On Fri, Apr 2, 2021 at 3:06 PM Zhihong Yu wrote:
> >
> > Hi,
> > For v6-0003-Parallel-Hash-Full-Right-Outer-Join.patch
> >
> > +* current_chunk_idx: index in current HashMemoryChunk
> >
> > The above comment seems to be better fit
On Fri, Apr 2, 2021 at 3:06 PM Zhihong Yu wrote:
>
> Hi,
> For v6-0003-Parallel-Hash-Full-Right-Outer-Join.patch
>
> +* current_chunk_idx: index in current HashMemoryChunk
>
> The above comment seems to be better fit for ExecScanHashTableForUnmatched(),
> instead of
Hi,
For v6-0003-Parallel-Hash-Full-Right-Outer-Join.patch
+* current_chunk_idx: index in current HashMemoryChunk
The above comment seems to be better fit
for ExecScanHashTableForUnmatched(), instead
of ExecParallelPrepHashTableForUnmatched.
I wonder where current_chunk_idx should belong
On Fri, Mar 5, 2021 at 8:31 PM Thomas Munro wrote:
>
> On Tue, Mar 2, 2021 at 11:27 PM Thomas Munro wrote:
> > On Fri, Feb 12, 2021 at 11:02 AM Melanie Plageman
> > wrote:
> > > I just attached the diff.
> >
> > Squashed into one patch for the cfbot to chew on, with a few minor
> > adjustments
On Fri, Feb 12, 2021 at 11:02 AM Melanie Plageman
wrote:
> I just attached the diff.
Squashed into one patch for the cfbot to chew on, with a few minor
adjustments to a few comments.
From 87c74af25940b0fc85186b0defe6e21ea2324c28 Mon Sep 17 00:00:00 2001
From: Melanie Plageman
Date: Wed, 4 Nov
On Tue, Dec 29, 2020 at 03:28:12PM +1300, Thomas Munro wrote:
> I had some feedback I meant to
> post in November but didn't get around to:
>
> * PHJ_BATCH_PROBING-- all probe
> - * PHJ_BATCH_DONE -- end
> +
> + * PHJ_BATCH_DONE -- queries not requiring inner fill
On Mon, Dec 28, 2020 at 9:49 PM Masahiko Sawada wrote:
> On Thu, Nov 5, 2020 at 7:34 AM Melanie Plageman
> wrote:
> > I've attached a patch with the corrections I mentioned upthread.
> > I've gone ahead and run pgindent, though, I can't say that I'm very
> > happy with the result.
> >
> > I'm
Hi Melanie,
On Thu, Nov 5, 2020 at 7:34 AM Melanie Plageman
wrote:
>
> I've attached a patch with the corrections I mentioned upthread.
> I've gone ahead and run pgindent, though, I can't say that I'm very
> happy with the result.
>
> I'm still not quite happy with the name
>
I've attached a patch with the corrections I mentioned upthread.
I've gone ahead and run pgindent, though, I can't say that I'm very
happy with the result.
I'm still not quite happy with the name
BarrierArriveAndDetachExceptLast(). It's so literal. As you said, there
probably isn't a nice name
On Mon, Sep 21, 2020 at 8:34 PM Thomas Munro wrote:
> On Tue, Sep 22, 2020 at 8:49 AM Melanie Plageman
> wrote:
> > On Wed, Sep 11, 2019 at 11:23 PM Thomas Munro
> wrote:
>
> I took it for a very quick spin and saw simple cases working nicely,
> but TPC-DS queries 51 and 97 (which contain full
On Tue, Sep 22, 2020 at 8:49 AM Melanie Plageman
wrote:
> On Wed, Sep 11, 2019 at 11:23 PM Thomas Munro wrote:
>> 1. You could probably make it so that the PHJ_BATCH_SCAN_INNER phase
>> in this patch (the scan for unmatched tuples) is executed by only one
>> process, using the
es to do so until either the query
> ends early or the subplan runs out of tuples. For example, Append
> processes its subplans one at a time until they're done -- it doesn't
> jump back and forth. Parallel Append doesn't necessarily run them in
> the order that they appear in th
g another one. If we ever had a node that
didn't adhere to that rule, then two Parallel Full Hash Join nodes
could dead lock, if some of the workers were stuck waiting in one
while some were stuck waiting in the other.
If we were happy to decree that that is a rule of the current
PostgreSQL executor,
39 matches
Mail list logo
