> Attached version removes the non-nulls array. That seems to speed
> everything up. Running the above query with 1 million rows averages 450ms,
> similar when using lead/lag.
Great. However, CFbot complains about the patch:
https://cirrus-ci.com/task/6364194477441024
Best reagards,
--
Tatsuo I
On Sat, Mar 8, 2025 at 6:15 PM David Rowley wrote:
> On Sun, 9 Mar 2025 at 10:39, Tom Lane wrote:
> > One thing that puzzled me a bit is that many of the outputs
> > show "ROWS UNBOUNDED PRECEDING" in window functions where that
> > definitely wasn't in the source query. Eventually I realized
>
In short, all the 4 patches look good to me. Thanks for picking this up!
On 06/03/2025 22:16, Andres Freund wrote:
On 2025-03-05 20:49:33 -0800, Noah Misch wrote:
This behaviour makes it really hard to debug problems. It'd have been a lot
easier to understand the problem if we'd seen psql's std
On Tue, Mar 4, 2025 at 9:04 PM Amit Kapila wrote:
>
> On Tue, Mar 4, 2025 at 12:23 PM vignesh C wrote:
> >
> > There is almost negligible dip with the above suggested way, the test
> > results for the same is given below(execution time is in milli
> > seconds):
> > Brach/records | 100 | 10
On Sat, Mar 8, 2025 at 12:49 PM Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 8:20 PM Álvaro Herrera wrote:
> >
> > On 2024-Mar-25, Alexander Korotkov wrote:
> >
> > > reindexdb: Add the index-level REINDEX with multiple jobs
> > >
> > > Straight-forward index-level REINDEX is not supported
On Fri, 31 Jan 2025 at 19:54, Jelte Fennema-Nio wrote:
>
> At the FOSDEM dev meeting we discussed potential improvements to the
> commitfest app and how to handle deploying future changes with minimal
> disruption to existing workflows. We're going to try a new approach:
> announcing a new commitf
On Sat, Mar 08, 2025 at 11:48:22PM +0100, Tomas Vondra wrote:
> Shortly after restarting this I got three more reports - all of them are
> related to strcoll_l. This is on c472a18296e4, i.e. with the asserts
> added in this thread etc. But none of those seem to fail.
> ==189168==at 0xA683CC: w
On Thu, 6 Mar 2025 at 08:43, Nikhil Kumar Veldanda
wrote:
>
> Hi all,
>
> The ZStandard compression algorithm [1][2], though not currently used for
> TOAST compression in PostgreSQL, offers significantly improved compression
> ratios compared to lz4/pglz in both dictionary-based and non-dictiona
On Sat, Mar 08, 2025 at 05:17:40PM -0500, Tom Lane wrote:
> It bothers me a bit that this proposes to do something as complicated
> as pg_class_aclcheck on a table we have no lock on. As you say, the
> lock we hold on the index would prevent DROP TABLE, but that doesn't
> mean we won't have any is
While thinking about the discussion at [1], I got annoyed about
how EXPLAIN still can't print a useful description of window
functions' window clauses (it just emits "OVER (?)"). The
difficulty is that there's no access to the original WindowClause
anymore; else we could re-use the ruleutils.c cod
On Sun, 9 Mar 2025 at 10:39, Tom Lane wrote:
> One thing that puzzled me a bit is that many of the outputs
> show "ROWS UNBOUNDED PRECEDING" in window functions where that
> definitely wasn't in the source query. Eventually I realized
> that that comes from window_row_number_support() and cohorts
On 3/7/25 17:32, Andres Freund wrote:
> Hi,
>
> On 2025-03-07 00:03:47 +0100, Tomas Vondra wrote:
>> while running check-world on 64-bit arm (rpi5 with Debian 12.9), I got a
>> couple reports like this:
>>
>> ==64550== Use of uninitialised value of size 8
>> ==64550==at 0xA62FE0: wrapper_ha
> From a quick test and skim of the relevant
> code, I think your patch is fine, though
Thanks for reviewing.
> And IIUC
> DROP TABLE first acquires a lock on the table and its dependent objects
> (e.g., indexes) before any actual deletions, so AFAICT there's no problem
> with using it in pg_class
On 3/8/25 21:38, Tomas Vondra wrote:
>
> I've restarted check-world with valgrind on my rpi5 machines, with
> current master. I can try running other stuff once that finishes in a
> couple hours.
>
Shortly after restarting this I got three more reports - all of them are
related to strcoll_l. Thi
> On 7 Mar 2025, at 4:40 PM, Aleksander Alekseev
> wrote:
>
> Hi,
>
>>> Sometimes support for base64url from RFC 4648 would be useful.
>>> Does anyone else need a patch like this?
>>
>> While not a frequent ask, it has been mentioned in the past. I think it
>> would
>> make sense to add so
"Todd M. Kover" writes:
> 2) some option that makes the code path for gss_store_cred_into optional
> (what would you want to call it?)
If we do this, I see no need to call it anything. Just make configure
probe for whether the selected GSS library has gss_store_cred_into.
The other options you
Nathan Bossart writes:
> I do see a concern upthread about increased deadlock risk [0], but your
> patch doesn't lock the table, but unless I'm wrong [1] (which is always
> possible), it doesn't need to lock it.
It bothers me a bit that this proposes to do something as complicated
as pg_class_acl
> "Todd M. Kover" writes:
> > To that end, I'd like to propose a --with-gssapi-client-only type option
> > that's mutually exclusive with --with-gssapi that will trigger gssapi
> > linkage in just libpq but not in the backend. --with-gssapi would just
> > turn on the same flag that --with-gss
On Sun, Mar 09, 2025 at 03:01:41AM +0530, Ayush Vatsa wrote:
> Maybe we can move ahead with the patch if we can see no other concerns.
I think we should allow some time in case others want to review the patch.
I do see a concern upthread about increased deadlock risk [0], but your
patch doesn't lo
On Sat, Mar 08, 2025 at 08:34:40PM +0530, Ayush Vatsa wrote:
>> I'm wondering whether setting missing_ok to true is correct here. IIUC we
>> should have an AccessShareLock on the index, but I don't know if that's
>> enough protection.
>
> Since we are already opening the relation with rel = relat
On Sat, Mar 08, 2025 at 01:43:52AM +0100, Magnus Hagander wrote:
> LGTM!
Thanks, committed.
--
nathan
On Thu, Feb 20, 2025 at 6:14 AM Dmitry Koval wrote:
> I got an Assert when executing an "INSERT ... ON CONFLICT ... UPDATE
> ..." query on partitioned table. Managed to reproduce this situation.
I was able to reproduce the assert with your instructions.
> I suggest replace Assert with an erro
I spent some quality time with this and wanted to revisit. It still
applies for pg17 and master of git (I was mucking about with master in
git).
> > As you may have surmised, I use a mac as a client and use gssapi pretty
> > heavily to interact with numerous postgresql databases. This has stop
>
> Until we add a fourth option, and then it becomes completely ambiguous as
>> to whether you wanted data+statstics, or you not-wanted schema.
>>
>>
> except it is perfectly clear that you *asked for* data and statistics, so
> you get what you asked for. however the user conjures in their heads w
"Todd M. Kover" writes:
> To that end, I'd like to propose a --with-gssapi-client-only type option
> that's mutually exclusive with --with-gssapi that will trigger gssapi
> linkage in just libpq but not in the backend. --with-gssapi would just
> turn on the same flag that --with-gssapi-client-only
On Fri, Mar 7, 2025 at 12:18 PM Peter Geoghegan wrote:
> What do you think of the attached WIP patch, which does things this
> way? Does this seem like the right general direction to you?
Attached is a more refined version of this patch, which is
substantially the same the same as the version I p
On 2/5/25 11:00 AM, Daniel Gustafsson wrote:
This fell off the ever-growing TODO again. Re-reading it I still think it's a
good idea, it applied almost cleanly still and still gives a slight performance
improvement along with the more interesting refactoring which will make caching
of expression
Jacob Brazeal writes:
> Several times in spell.c, we call strtol and then check the errno, but we
> do not clear out errno = 0 before strtol, as is customary (and done
> everywhere else in the codebase that I could find.) This could
> hypothetically lead to us incorrectly logging an error.
Yeah.
On Fri, Mar 7, 2025 at 10:40 PM Corey Huinker
wrote:
>
>> if you want everything --include=schema,data,statistics (presumably
>> redundant with the default behavior)
>> if you want schema only --include=schema
>> if you want "everything except schema" --include=data,statistics
>>
>
> Until we add
On 2025-03-05 We 7:10 PM, Ian Lawrence Barwick wrote:
Hi
2025年3月1日(土) 2:58 Florents Tselai :
Please add this to the next Commitfest at https://commitfest.postgresql.org/52/
Added ; thanks
https://commitfest.postgresql.org/patch/5260/
I see this was committed, but there's a small formatti
Hi,
I think there is still some problem with the patch. I am not able to apply it
to the master branch.
Can you please take another look at it?
Thanks,
Akshat Jaimini
Hi,
On 2025-03-08 17:06:38 +0200, Alexander Korotkov wrote:
> On Sat, Mar 8, 2025 at 3:41 PM Andres Freund wrote:
> >
> > On 2025-03-08 08:02:41 -0500, Andres Freund wrote:
> > > From the C/C++ standard atomics model it doesn't make sense to say that a
> > > failed CAS has release semantics, as t
On Sat, Mar 8, 2025 at 3:41 PM Andres Freund wrote:
>
> On 2025-03-08 08:02:41 -0500, Andres Freund wrote:
> > From the C/C++ standard atomics model it doesn't make sense to say that a
> > failed CAS has release semantics, as there simply isn't a write that could
> > be
> > ordered! What their b
> I'm wondering whether setting missing_ok to true is correct here. IIUC we
> should have an AccessShareLock on the index, but I don't know if that's
> enough protection.
Since we are already opening the relation with rel = relation_open(relOid,
AccessShareLock);,
if relOid does not exist, it wil
Hi,
On 2025-03-08 08:02:41 -0500, Andres Freund wrote:
> From the C/C++ standard atomics model it doesn't make sense to say that a
> failed CAS has release semantics, as there simply isn't a write that could be
> ordered! What their barriers guarantee is ordering between multiple memory
> operati
On Sat, Mar 8, 2025 at 12:04 PM Masahiko Sawada wrote:
>
> Hi,
>
> On Sun, Oct 27, 2024 at 12:05 PM Kirill Reshke wrote:
> >
> > On Wed, 14 Aug 2024 at 11:35, Steven Niu wrote:
> > >
> > > Junwang, Kirill,
> > >
> > > The split work has been done. I created a new patch for removing
> > > redund
On 2025-03-07 Fr 8:52 AM, Robert Haas wrote:
On Thu, Mar 6, 2025 at 7:03 PM Julien Rouhaud wrote:
Honestly, it's been years of people complaining on one thing or another about
lapwing without ever asking for a change. Was it really hard to ask "can you
remove the -Werror it's not useful anymor
Hi,
On 2025-03-08 14:12:13 +0200, Alexander Korotkov wrote:
> I'm not an expert in formal specifications of memory models. But I'm quite
> surprised we're discussing whether memory barrier on compare-exchange
> failure might matter. For me at least the fact
> that __atomic_compare_exchange_n() h
Hi, Andres!
On Fri, Mar 7, 2025 at 7:54 PM Alexander Korotkov
wrote:
> On Fri, Mar 7, 2025 at 7:46 PM Andres Freund wrote:
> > On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 7:38 PM Andres Freund
wrote:
> > > > On 2025-03-07 19:15:23 +0200, Alexander Korotk
On Fri, Mar 7, 2025 at 8:20 PM Álvaro Herrera wrote:
>
> On 2024-Mar-25, Alexander Korotkov wrote:
>
> > reindexdb: Add the index-level REINDEX with multiple jobs
> >
> > Straight-forward index-level REINDEX is not supported with multiple jobs as
> > we cannot control the concurrent processing of
On Sat, Mar 8, 2025 at 11:57 AM Álvaro Herrera wrote:
>
> On 2025-Mar-07, Álvaro Herrera wrote:
>
> > I tested this, because of a refactoring suggestion [1] and I find that
> > it's rather completely broken.
>
> I think we need significantly more complex scheduling code if we want
> this to actual
On Wed, 2025-03-05 at 23:04 -0500, Corey Huinker wrote:
>
> Anyway, here's a rebased set of the existing up-for-consideration
> patches, plus the optimization of avoiding querying on non-expression
> indexes.
Patch 0001 contains a bug: it returns REQ_STATS early, before doing any
exclusions.
But
hi.
patch attached to fix the above thread mentioned issue, related tests added.
also there are several compiler warnings at [0] for virtual generated
column domain patch,
i did some minor adjustment, let's see how it goes.
[0] https://cirrus-ci.com/task/4550600270020608
From 0985d7a779287feaa1a
On Sat, Mar 8, 2025 at 1:37 AM Junwang Zhao wrote:
>
> Hi Masahiko,
>
> > > I've looked at the patch and have some comments:
> > >
> > > The patch removes smgrclose() calls following smgrdounlinkall(), for
> > > example:
> > >
> > > --- a/src/backend/catalog/storage.c
> > > +++ b/src/backend/cata
On 2025-Mar-07, Álvaro Herrera wrote:
> I tested this, because of a refactoring suggestion [1] and I find that
> it's rather completely broken.
I think we need significantly more complex scheduling code if we want
this to actually work, possibly even having to hack the ParallelSlot
API some, so t
Hello!
I was thinking the same thing once - and you may
see db989184cda7f4aa1ff764cca96142029e7e093b for the special comment about
that :)
https://github.com/postgres/postgres/commit/db989184cda7f4aa1ff764cca96142029e7e093b
Hi Masahiko,
> > I've looked at the patch and have some comments:
> >
> > The patch removes smgrclose() calls following smgrdounlinkall(), for
> > example:
> >
> > --- a/src/backend/catalog/storage.c
> > +++ b/src/backend/catalog/storage.c
> > @@ -686,9 +686,6 @@ smgrDoPendingDeletes(bool isCommi
47 matches
Mail list logo
