On Wed, Feb 21, 2024 at 6:42 PM Thomas Munro wrote:
> Yeah, right. I will aim to get this into the tree next week. First,
> there are a couple of minor issues to resolve around freeing that
> Heikki mentioned. Then there is the question of whether we think this
> might be a candidate for
On Thu, Feb 22, 2024 at 5:37 PM Andrei Lepikhov
wrote:
> On 22/2/2024 06:42, Thomas Munro wrote:
> > extreme skew for one version of the problem, but even with zero/normal
> > skewness and perfect estimation of the number of partitions, if you
Sorry, I meant to write "but even with no
On 22/2/2024 06:42, Thomas Munro wrote:
On Wed, Feb 21, 2024 at 7:34 PM Andrei Lepikhov
wrote:
I see in [1] that the reporter mentioned a delay between the error
message in parallel HashJoin and the return control back from PSQL. Your
patch might reduce this delay.
Also, I have the same
On Wed, Feb 21, 2024 at 7:34 PM Andrei Lepikhov
wrote:
> I see in [1] that the reporter mentioned a delay between the error
> message in parallel HashJoin and the return control back from PSQL. Your
> patch might reduce this delay.
> Also, I have the same complaint from users who processed
Hi,
I see in [1] that the reporter mentioned a delay between the error
message in parallel HashJoin and the return control back from PSQL. Your
patch might reduce this delay.
Also, I have the same complaint from users who processed gigabytes of
data in parallel HashJoin. Presumably, they also
On Wed, Sep 27, 2023 at 11:42 PM Heikki Linnakangas wrote:
>
> Looks good to me too at a quick glance. There's this one "XXX free"
> comment though:
>
> > for (int i = 1; i < old_nbatch; ++i)
> > {
> > ParallelHashJoinBatch *shared =
> >
On 11/05/2023 00:00, Jehan-Guillaume de Rorthais wrote:
On Wed, 10 May 2023 15:11:20 +1200
Thomas Munro wrote:
The reason I didn't do this earlier is that sharedtuplestore.c
continues the pre-existing tradition where each parallel process
counts what it writes against its own temp_file_limit.
Hi,
Thanks for working on this!
On Wed, 10 May 2023 15:11:20 +1200
Thomas Munro wrote:
> One complaint about PHJ is that it can, in rare cases, use a
> surprising amount of temporary disk space where non-parallel HJ would
> not. When it decides that it needs to double the number of batches to
Hi,
One complaint about PHJ is that it can, in rare cases, use a
surprising amount of temporary disk space where non-parallel HJ would
not. When it decides that it needs to double the number of batches to
try to fit each inner batch into memory, and then again and again
depending on your level
