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 leas
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 so
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 12:25:2
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:
save
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 no
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
On Mon, Mar 27, 2023 at 7:04 PM Thomas Munro wrote:
> I found another problem. I realised that ... FULL JOIN ... LIMIT n
> might be able to give wrong answers with unlucky scheduling.
> Unfortunately I have been unable to reproduce the phenomenon I am
> imagining yet but I can't think of any mech
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 strateg
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 catch
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 var
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(&accessor->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(&accessor->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 :(
> https://c
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.
> > https://cirrus-ci
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 da
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 re
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:
https://cirrus-ci.com/task/
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 Plagema
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 for
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 ExecParallelPrepHashTableF
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 (cons
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 t
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 20
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 sti
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
> BarrierArriveAndDeta
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 for
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 "detach-and-see-if
On Wed, Sep 11, 2019 at 11:23 PM Thomas Munro
wrote:
>
> While thinking about looping hash joins (an alternative strategy for
> limiting hash join memory usage currently being investigated by
> Melanie Plageman in a nearby thread[1]), the topic of parallel query
> deadlock hazards came back to ha
38 matches
Mail list logo
