Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t67wH-00Ap7N-Qb for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Oct 2024 12:36:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t67wG-008aTs-0W for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Oct 2024 12:36:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t67wF-008aTj-Mz for pgsql-hackers@lists.postgresql.org; Wed, 30 Oct 2024 12:36:40 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t67wE-003omE-0l for pgsql-hackers@lists.postgresql.org; Wed, 30 Oct 2024 12:36:39 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2fb470a8b27so7763621fa.1 for ; Wed, 30 Oct 2024 05:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730291797; x=1730896597; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5UfrPdtBNdwza0Du5eqIJl2Al8A8r1APDExPnZTGz/k=; b=WKqUWeinqJDCRNsL+KeE0ue8pz755dUTDdkhyxKMVjQG1RDnkZpO5eUaisi/xaNIVi y8g16DC1M2I11luuRnxIiMKSesy28z2xh6/vmyz1xfLMBBTHlnHsxixYKI/3AZe4G3jZ CAuZ0o80uJFVyMz3J/UdE8oDvjenrm2k/M8vqkFgYQbgyt4mWB0DQFYj2dDo8oqeANVc xwgzEGF7Zzc16XvuGO1VRHRf41REUu/br3w+x3fLFwshzikrxuwiThcZLEZdk5fNziNU puLPGQDqnwnBTHV/fcFoie0YFRtS0vKvgMmYz2Yk+uwHXSuxErzaqbIps338DeCAnQws zDlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730291797; x=1730896597; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5UfrPdtBNdwza0Du5eqIJl2Al8A8r1APDExPnZTGz/k=; b=YlnS+AqFPu2YCmVnc2fv7q45o1qeBVrTFLR36m7YQruEpNiQyYbLawgVMYOIyZKa7+ va81RKl7E4HpV3JP3s1VXKXY5GMemLgCPOGiXp+w68pIYw3iBCExvGJJPVypa2Z59xB8 Bje8vteq5llFVjC6Bm3kOfFKn1kqucw8IV2bmDDDLN+RfuSo8jItr7ILgWPEn39fw+QM 7hBKjyk0FNdHLfTz3Ol/xS4i2rMtq/zcRcGg7u2ZbRUAiF5Dtv3eieDNnCy3J66ALU9b HleOFg5PFkDLVWxl0Xq7oEsJwfaRnIE920HGvmZMVXSUi4/L6NFtytiH71C9jisdK4jt 8jDQ== X-Forwarded-Encrypted: i=1; AJvYcCUwOXEx+P0mI8/oxTF+nicpUogC/13u0dvmATXsK1Sr+H5Rmj3pU4UwZB05sUdhS2suUaosS1IvEa42N49g@lists.postgresql.org X-Gm-Message-State: AOJu0YzkaQLeRp9Zz1Y9LrwEJASxP7b0g8CbdcD/CGpCXn4gdBar4i2w BTxPtLpaVIHDc1Y1eQmmKVskoL4WxjS9tXqS0mxkMiBF2aRFO0zW8k79rjsZ3KrWZ7/OwxFJyNG lWRieuUnidQYQ8PIFfZotb9+nai5d42I6a6CB3Pj8jIM= X-Google-Smtp-Source: AGHT+IFDmUxlv21G79GHumQdpzRGxT6GnenG0TymiWZRodK3csXkDGp+ShhXBAZ9yxsuZHXrhBab+Hmb5v5Dfdu2WvM= X-Received: by 2002:a05:6512:10d2:b0:539:fa32:6c84 with SMTP id 2adb3069b0e04-53c3161b790mr675063e87.18.1730291796755; Wed, 30 Oct 2024 05:36:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Junwang Zhao Date: Wed, 30 Oct 2024 20:36:25 +0800 Message-ID: Subject: Re: Wrong result when enable_partitionwise_join is on if collation of PartitionKey and Column is different. To: jian he Cc: Tender Wang , Amit Langote , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Oct 30, 2024 at 11:58=E2=80=AFAM jian he wrote: > > I missed a case when column collation and partition key collation are > the same and indeterministic. > that should be fine for partition-wise join. > so v2 attached. > > have_partkey_equi_join, match_expr_to_partition_keys didn't do any > collation related check. > propose v2 change disallow partitionwise join for case when > column collation is indeterministic *and* is differ from partition > key's collation. > > the attached partition_wise_join_collation.sql is the test script. > you may use it to compare with the master behavior. What if the partkey collation and column collation are both deterministic, but with different sort order? I'm not familiar with this part of the code base, but it seems to me the partition wise join should use partkey collation instead of column collatio= n, because it's the partkey collation that decides which partition a row to be dispatched. What Jian proposed is also reasonable but seems another aspect of $subject? Just some random thought, might be wrong ;( --=20 Regards Junwang Zhao