Hello Michael,
> [[PGP Signed Part:Undecided]]
> On Mon, Apr 08, 2024 at 12:25:00PM +0800, Andy Fan wrote:
>> During the review of using extended statistics to improve join estimates
>> [1], I found some code level optimization opportunities which apply to
>> existing code as well. To make
On Mon, Apr 08, 2024 at 12:25:00PM +0800, Andy Fan wrote:
> During the review of using extended statistics to improve join estimates
> [1], I found some code level optimization opportunities which apply to
> existing code as well. To make the discussion easier, open this new
> thread.
Is that
On Fri, Apr 05, 2024 at 06:19:20PM +0200, Jelte Fennema-Nio wrote:
> Agreed. While not a full solution, I think this patch is still good to
> address some of the pain: Waiting 10 seconds at the end of my build
> with only 1 of my 10 cores doing anything.
>
> So while this doesn't decrease CPU
On Thu, Mar 21, 2024 at 11:33 PM Bharath Rupireddy
wrote:
>
> Please find the v26 patches after rebasing.
Commit f3ff7bf83b added a check in WALReadFromBuffers to ensure the
requested WAL is not past the WAL that's copied to WAL buffers. So,
I've dropped v26-0001 patch.
I've attached v27
Hi,
On 2024-04-08 16:18:21 +1200, David Rowley wrote:
> On Mon, 8 Apr 2024 at 16:08, Andres Freund wrote:
> > I think visible would be ok, the serialization checks are IMO about
> > visibility too. But if you'd prefer I'd also be ok with something like
> > page_collect_tuples()?
>
> That's ok
On Thu, Apr 04, 2024 at 06:08:40PM +0900, Etsuro Fujita wrote:
> Pushed. Sorry for the delay.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Mon, Apr 8, 2024 at 11:53 AM Melanie Plageman
wrote:
> I've reviewed v6. I think you should mention in the docs that it only
> works for shared buffers -- so specifically not buffers containing
> blocks of temp tables.
Thanks for looking! The whole pg_buffercache extension is for working
On Mon, Apr 8, 2024 at 11:21 AM jian he wrote:
>
> On Mon, Apr 8, 2024 at 12:34 AM jian he wrote:
> >
> > On Sun, Apr 7, 2024 at 9:36 PM Amit Langote wrote:
> > > 0002 needs an expanded commit message but I've run out of energy today.
> > >
>
> other than that, it looks good to me.
one more
On Fri, Apr 5, 2024 at 1:18 AM vignesh C wrote:
>
> On Tue, 2 Apr 2024 at 13:08, Masahiko Sawada wrote:
> >
> > On Mon, Apr 1, 2024 at 10:41 PM vignesh C wrote:
> > >
> > > On Thu, 28 Mar 2024 at 13:05, Masahiko Sawada
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Thank you for the patch!
On Sun, Apr 7, 2024 at 3:06 AM Andres Freund wrote:
>
> On 2024-04-06 10:58:32 +0530, Amit Kapila wrote:
> > On Sat, Apr 6, 2024 at 10:13 AM Amit Kapila wrote:
> > >
> >
> > There are still a few pending issues to be fixed in this feature but
> > otherwise, we have committed all the main
On Mon, Apr 8, 2024 at 12:10 PM Andres Freund wrote:
> On 2024-04-07 11:07:58 +1200, Thomas Munro wrote:
> > I thought of a better name for the bufmgr.c function though:
> > InvalidateUnpinnedBuffer(). That name seemed better to me after I
> > festooned it with warnings about why exactly it's
Hello,
During the review of using extended statistics to improve join estimates
[1], I found some code level optimization opportunities which apply to
existing code as well. To make the discussion easier, open this new
thread.
I don't know how to name the thread name, just use the patch 1 for
On Mon, 8 Apr 2024 at 16:08, Andres Freund wrote:
>
> On 2024-04-08 15:43:12 +1200, David Rowley wrote:
> > I understand wanting to avoid the long name. I'd rather stay clear of
> > "visible", but don't feel as strongly about this as it's static.
>
> I think visible would be ok, the
On Fri, Apr 05, 2024 at 08:07:51PM -0500, Nathan Bossart wrote:
> On Sat, Apr 06, 2024 at 08:56:04AM +0900, Michael Paquier wrote:
>> There is pg_read_all_stats as well, so I don't see a big issue in
>> requiring to be a member of this role as well for the sake of what's
>> proposing here.
>
>
Hi,
On 2024-04-08 15:43:12 +1200, David Rowley wrote:
> On Mon, 8 Apr 2024 at 15:13, Andres Freund wrote:
> > Off-list Melanie suggested heap_page_collect_visible_tuples(). Given the
> > separate callsites (making long names annoying) and the fact that it's
> > really
> > specific to one
08.04.2024 01:15, Alexander Korotkov wrote:
Thank you for spotting this. This seems like a missing check. I'm
going to get a closer look at this tomorrow.
Thanks!
There is also an anomaly with the MERGE command:
CREATE TABLE t1 (i int, a int, b int, c int) PARTITION BY RANGE (a, b);
CREATE
On Mon, Apr 8, 2024 at 10:26 AM Melanie Plageman
wrote:
> On Sun, Apr 07, 2024 at 03:00:00PM -0700, Andres Freund wrote:
> > On 2024-04-07 16:59:26 -0400, Melanie Plageman wrote:
> > > From 862b7ac81cdafcda7b525e02721da14e46265509 Mon Sep 17 00:00:00 2001
> > > From: Melanie Plageman
> > > Date:
On Mon, 8 Apr 2024 at 15:13, Andres Freund wrote:
> I kinda don't like heap_prepare_pagescan(), but heapgetpage() is worse. And I
> don't have a great alternative suggestion.
It came around from having nothing better. I was keen not to have the
name indicate it was only for checking visibility
On Mon, Apr 8, 2024 at 12:34 AM jian he wrote:
>
> On Sun, Apr 7, 2024 at 9:36 PM Amit Langote wrote:
> > 0002 needs an expanded commit message but I've run out of energy today.
> >
>
+/*
+ * Fetch next row from a JsonTablePlan's path evaluation result and from
+ * any child nested path(s).
+ *
Hi,
On 2024-04-08 14:43:21 +1200, David Rowley wrote:
> On Sun, 7 Apr 2024 at 19:30, Andres Freund wrote:
> > Good call. Added and pushed.
>
> I understand you're already aware of the reference in the comment to
> heapgetpage(), which no longer exists as of 44086b097.
Yea,
On Sun, 7 Apr 2024 at 19:30, Andres Freund wrote:
> Good call. Added and pushed.
I understand you're already aware of the reference in the comment to
heapgetpage(), which no longer exists as of 44086b097.
Melanie and I had discussed the heap_prepare_pagescan() name while I
was reviewing that
On Sun, Apr 7, 2024 at 9:57 PM Peter Geoghegan wrote:
> On Sun, Apr 7, 2024 at 9:50 PM Tom Lane wrote:
> > those first two Asserts are redundant with the "if" as well.
>
> I'll get rid of those other two assertions as well, then.
Done that way.
--
Peter Geoghegan
On 2024-04-07 21:41:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I can't see a way it could hurt in the back branches, so I'm inclined to
> > backpatch the pfree?
>
> +1
Done
On Sun, Apr 7, 2024 at 9:50 PM Tom Lane wrote:
> If you're doing that, then surely
>
> if (j != (BTEqualStrategyNumber - 1) ||
> !(xform[j].skey->sk_flags & SK_SEARCHARRAY))
> {
> ...
> }
>
Peter Geoghegan writes:
> The assertions in question are arguably redundant. There are very
> similar assertions just a little earlier on, as we initially set up
> the array stuff (right before _bt_compare_scankey_args is called).
> I'll just remove the "Assert(xform[j].ikey == array->scan_key)"
Andres Freund writes:
> On 2024-04-07 21:03:53 -0400, Tom Lane wrote:
>> I realize this function is only debug support, but wouldn't it
>> be appropriate to pfree(collisions) before exiting?
> It indeed looks like that memory should be freed. Very odd that coverity
> started to complain about
On 08/04/2024 04:28, Tom Lane wrote:
Heikki Linnakangas writes:
Committed this. Thank you to everyone involved!
Looks like perlcritic isn't too happy with the test code:
koel and crake say
./src/test/libpq_encryption/t/001_negotiate_encryption.pl: Return value of
flagged function ignored -
On Sun, Apr 7, 2024 at 9:25 PM Tom Lane wrote:
> Perhaps this'd help:
>
> -Assert(xform[j].ikey == array->scan_key);
> +Assert(array && xform[j].ikey == array->scan_key);
>
> If that doesn't silence it, I'd be prepared to just dismiss the
> warning.
Nathan Bossart writes:
> On Sun, Apr 07, 2024 at 08:23:32PM -0500, Nathan Bossart wrote:
>> The Intel documentation for _mm256_undefined_si256() [0]
>> indicates that it is intended to return "undefined elements," so it seems
>> like the use of an uninitialized variable might be intentional.
>
Hi,
On 2024-04-07 21:03:53 -0400, Tom Lane wrote:
> Today's Coverity run produced this:
>
> /srv/coverity/git/pgsql-git/postgresql/src/include/lib/simplehash.h: 1138 in
> bh_nodeidx_stat()
> 1132 avg_collisions = 0;
> 1133 }
> 1134
> 1135 sh_log("size: "
On Sun, Apr 07, 2024 at 08:23:32PM -0500, Nathan Bossart wrote:
> The Intel documentation for _mm256_undefined_si256() [0]
> indicates that it is intended to return "undefined elements," so it seems
> like the use of an uninitialized variable might be intentional.
See also
Heikki Linnakangas writes:
> Committed this. Thank you to everyone involved!
Looks like perlcritic isn't too happy with the test code:
koel and crake say
./src/test/libpq_encryption/t/001_negotiate_encryption.pl: Return value of
flagged function ignored - chmod at line 138, column 2. See
Committed this. Thank you to everyone involved!
On 04/04/2024 14:08, Matthias van de Meent wrote:
Patch 0003:
The read size in secure_raw_read is capped to port->raw_buf_remaining
if the raw buf has any data. While the user will probably call into
this function again, I think that's a waste of
Peter Geoghegan writes:
> On Sun, Apr 7, 2024 at 8:48 PM Tom Lane wrote:
>> Coverity pointed out something that looks like a potentially live
>> problem in 5bf748b86:
>> ... which certainly makes it look like array->scan_key could be
>> a null-pointer dereference.
> But the
On Sun, Apr 07, 2024 at 08:42:12PM -0400, Tom Lane wrote:
> Today's Coverity run produced this warning, which seemingly was
> triggered by one of these commits, but I can't make much sense
> of it:
>
> *** CID 1596255: Uninitialized variables (UNINIT)
>
On Sat, Apr 06, 2024 at 10:34:46AM +0500, Andrey M. Borodin wrote:
> I find name of the function "injection_points_local()" strange,
> because there is no verb in the name. How about
> "injection_points_set_local"?
That makes sense.
> I'm not sure if we should refactor anything here, but
>
On Mon, Apr 8, 2024 at 10:26 AM Melanie Plageman
wrote:
> On Sun, Apr 07, 2024 at 03:00:00PM -0700, Andres Freund wrote:
> > > src/backend/commands/analyze.c | 89 ++
> > > 1 file changed, 26 insertions(+), 63 deletions(-)
> >
> > That's a very nice demonstration
On Sun, Apr 7, 2024 at 8:48 PM Tom Lane wrote:
>
> Coverity pointed out something that looks like a potentially live
> problem in 5bf748b86:
>
> /srv/coverity/git/pgsql-git/postgresql/src/backend/access/nbtree/nbtutils.c:
> 2950 in _bt_preprocess_keys()
> 2944 * need
Today's Coverity run produced this:
/srv/coverity/git/pgsql-git/postgresql/src/include/lib/simplehash.h: 1138 in
bh_nodeidx_stat()
1132 avg_collisions = 0;
1133 }
1134
1135 sh_log("size: " UINT64_FORMAT ", members: %u, filled: %f, total
chain: %u, max chain: %u,
Hi Andres,
Thanks for reviewing this!
In <20240407232635.fq4kc5556laha...@awork3.anarazel.de>
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Sun,
7 Apr 2024 16:26:35 -0700,
Andres Freund wrote:
> This seems like a fair amount of extra configure tests.
Coverity complained that this patch leaks memory:
/srv/coverity/git/pgsql-git/postgresql/src/bin/pg_combinebackup/load_manifest.c:
212 in load_backup_manifest()
206 bytes_left -= rc;
207 json_parse_manifest_incremental_chunk(
208
Coverity pointed out something that looks like a potentially live
problem in 5bf748b86:
/srv/coverity/git/pgsql-git/postgresql/src/backend/access/nbtree/nbtutils.c:
2950 in _bt_preprocess_keys()
2944 * need to make sure that we don't throw away
an array
2945
Nathan Bossart writes:
> Here is what I have staged for commit, which I intend to do shortly.
Today's Coverity run produced this warning, which seemingly was
triggered by one of these commits, but I can't make much sense
of it:
*** CID 1596255: Uninitialized variables (UNINIT)
On Mon, Apr 08, 2024 at 01:34:37AM +0300, Alexander Korotkov wrote:
> Hi!
>
> On Mon, Apr 1, 2024 at 9:38 AM Andrei Lepikhov
> wrote:
> > On 28/3/2024 16:54, Alexander Korotkov wrote:
> > > The current patch has a boolean guc enable_or_transformation.
> > > However, when we have just a few ORs
Hi,
On 2024-04-07 11:07:58 +1200, Thomas Munro wrote:
> I thought of a better name for the bufmgr.c function though:
> InvalidateUnpinnedBuffer(). That name seemed better to me after I
> festooned it with warnings about why exactly it's inherently racy and
> only for testing use.
I still
On Sat, Apr 6, 2024 at 7:08 PM Thomas Munro wrote:
>
> On second thoughts, I think the original "invalidate" terminology was
> fine, no need to invent a new term.
>
> I thought of a better name for the bufmgr.c function though:
> InvalidateUnpinnedBuffer(). That name seemed better to me after I
Hi,
On 2024-04-08 02:25:17 +0300, Alexander Korotkov wrote:
> On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
> > On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
> > > I've pushed 0001, 0002 and 0006.
> >
> > I briefly looked at 27bc1772fc81 and I don't think the state post this
>
On Mon, Apr 8, 2024 at 2:25 AM Alexander Korotkov wrote:
> On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
> > On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
> > > I've pushed 0001, 0002 and 0006.
> >
> > I briefly looked at 27bc1772fc81 and I don't think the state post this
> >
Hi,
On 2024-03-15 18:36:55 +0900, Sutou Kouhei wrote:
> +warning_level = get_option('warning_level')
> +# See https://mesonbuild.com/Builtin-options.html#details-for-warning_level
> for
> +# warning_level values.
> +if warning_level == '1'
> + common_builtin_flags += ['-Wall', '/W2']
> +elif
Hi,
On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
> On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
> > I've pushed 0001, 0002 and 0006.
>
> I briefly looked at 27bc1772fc81 and I don't think the state post this commit
> makes sense. Before this commit another block based AM could
> On 8 Apr 2024, at 01:04, Andres Freund wrote:
> What makes you think that's unrelated? To me that looks like the same issue?
Nvm, I misread the assert, ETOOLITTLESLEEP. Sorry for the noise.
--
Daniel Gustafsson
On Mon, Apr 8, 2024 at 2:07 AM Andres Freund wrote:
>
> Looking at the code, the failure isn't suprising anymore:
> chardata[MaxBlocktableEntrySize];
> BlocktableEntry *page = (BlocktableEntry *) data;
>
> 'char' doesn't enforce any alignment, but you're storing a
On Mon, 8 Apr 2024 at 09:09, Andres Freund wrote:
> I suspect that KeeperBlock() isn't returning true, because IsKeeperBlock
> misses
> the MAXALIGN(). I think that about fits with:
Thanks for investigating that.
I've just pushed a fix for the macro and also adjusted a location
which was
Hi,
On 2024-04-08 00:55:42 +0200, Daniel Gustafsson wrote:
> > On 8 Apr 2024, at 00:41, Tom Lane wrote:
> >
> > Tomas Vondra writes:
> >> Yup, changing it to this:
> >
> >> #define KeeperBlock(set) ((BumpBlock *) ((char *) (set) +
> >> MAXALIGN(sizeof(BumpContext
> >
> >> fixes the issue
> On 8 Apr 2024, at 00:46, Michael Paquier wrote:
>
> On Sat, Apr 06, 2024 at 07:47:43PM +0200, Daniel Gustafsson wrote:
>> My apologies, I thought I did but clearly failed. My point was that this is
>> a
>> special/corner case where we try to find one of two different libraries (with
>>
> On 8 Apr 2024, at 00:41, Tom Lane wrote:
>
> Tomas Vondra writes:
>> Yup, changing it to this:
>
>> #define KeeperBlock(set) ((BumpBlock *) ((char *) (set) +
>> MAXALIGN(sizeof(BumpContext
>
>> fixes the issue for me.
>
> Mamba is happy with that change, too.
Unrelated to that one,
On Thu, Apr 04, 2024 at 03:10:27PM +1300, David Rowley wrote:
> Someone asked me about this, so thought it might be useful to post here.
I've received the same question.
> To express this as UTC, It's:
>
> postgres=# select '2024-04-08 00:00-12:00' at time zone 'UTC';
> timezone
>
On Sat, Apr 06, 2024 at 07:47:43PM +0200, Daniel Gustafsson wrote:
> My apologies, I thought I did but clearly failed. My point was that this is a
> special/corner case where we try to find one of two different libraries (with
> different ideas about backwards compatability etc) for supporting a
Tomas Vondra writes:
> Yup, changing it to this:
> #define KeeperBlock(set) ((BumpBlock *) ((char *) (set) +
> MAXALIGN(sizeof(BumpContext
> fixes the issue for me.
Mamba is happy with that change, too.
regards, tom lane
Hi!
On Mon, Apr 1, 2024 at 9:38 AM Andrei Lepikhov
wrote:
> On 28/3/2024 16:54, Alexander Korotkov wrote:
> > The current patch has a boolean guc enable_or_transformation.
> > However, when we have just a few ORs to be transformated, then we
> > should get less performance gain from the
> On 7 Apr 2024, at 18:51, Daniel Gustafsson wrote:
>> On 7 Apr 2024, at 18:28, Andres Freund wrote:
>> I'm ok with printing path + some content or just the path.
>
> I think printing the last 512 bytes or so would be a good approach, I'll take
> care of it later tonight. That would be a
On Sun, Apr 07, 2024 at 03:00:00PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-04-07 16:59:26 -0400, Melanie Plageman wrote:
> > From 1dc2343661f3edb3b1bc4307afb0e956397eb76c Mon Sep 17 00:00:00 2001
> > From: Melanie Plageman
> > Date: Sun, 7 Apr 2024 14:55:22 -0400
> > Subject: [PATCH v10
Hi, Alexander!
On Sun, Apr 7, 2024 at 10:00 PM Alexander Lakhin wrote:
> 07.04.2024 01:22, Alexander Korotkov wrote:
> > I've pushed 0001 and 0002. I didn't push 0003 for the following reasons.
>
> Please try the following (erroneous) query:
> CREATE TABLE t1(i int, t text) PARTITION BY LIST
Hi,
On 2024-04-08 09:36:59 +1200, Thomas Munro wrote:
> I've been on the fence about that flag for sequential scan... Some
> days I want to consider changing to READ_STREAM_DEFAULT and relying on
> our "anti-heuristics" to suppress advice, which would work out the
> same in most cases but might
On Apr 7, 2024, at 15:46, Erik Wienhold wrote:
> I guess jsonpath assumes that hex, octal, and binary literals are
> integers. So there's no ambiguity about any fractional part that might
> follow.
Yeah, that’s what the comment in the flex file says:
Hi,
On 2024-04-07 16:59:26 -0400, Melanie Plageman wrote:
> From 1dc2343661f3edb3b1bc4307afb0e956397eb76c Mon Sep 17 00:00:00 2001
> From: Melanie Plageman
> Date: Sun, 7 Apr 2024 14:55:22 -0400
> Subject: [PATCH v10 1/3] Make heapam_scan_analyze_next_[tuple|block] static.
>
> 27bc1772fc81
David Rowley , 6 Nis 2024 Cmt, 04:34 tarihinde şunu
yazdı:
> Does anyone else want to try the attached script on the v5 patch to
> see if their numbers are better?
>
I'm seeing the below results with your script on my machine (). I ran it
several times, results were almost similar each time.
Hi,
On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
> I've pushed 0001, 0002 and 0006.
I briefly looked at 27bc1772fc81 and I don't think the state post this commit
makes sense. Before this commit another block based AM could implement analyze
without much code duplication. Now a large
On Sun, Apr 7, 2024 at 1:34 PM Melanie Plageman
wrote:
> Attached v13 0001 is your fix and 0002 is a new version of the
> sequential scan streaming read user. Off-list Andres mentioned that I
> really ought to separate the parallel and serial sequential scan users
> into two different callbacks.
Hi,
On Mon, 8 Apr 2024 at 00:01, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Sun, 7 Apr 2024 at 20:33, Nazir Bilal Yavuz wrote:
> >
> > Hi,
> >
> > On Tue, 2 Apr 2024 at 11:40, Thomas Munro wrote:
> > >
> > > I had been planning to commit v14 this morning but got cold feet with
> > > the BMR-based
On 4/7/24 23:09, Andres Freund wrote:
> Hi,
>
> On 2024-04-07 22:35:47 +0200, Tomas Vondra wrote:
>> I haven't investigated, but I'd considering it works on 64-bit, I guess
>> it's not considering alignment somewhere. I can dig more if needed.
>
> I think I may the problem:
>
>
> #define
Peter Smith writes:
> Here is a similar update for another page: "55.4 Streaming Replication
> Protocol" [0]. This patch was prompted by a review comment reply at
> [1] (#2).
> I've used text almost the same as the boilerplate text added by the
> previous commit [2]
Pushed, except I put it at
Hi,
On 2024-04-07 22:35:47 +0200, Tomas Vondra wrote:
> I haven't investigated, but I'd considering it works on 64-bit, I guess
> it's not considering alignment somewhere. I can dig more if needed.
I think I may the problem:
#define KeeperBlock(set) ((BumpBlock *) ((char *) (set) +
Hi,
On Sun, 7 Apr 2024 at 20:33, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Tue, 2 Apr 2024 at 11:40, Thomas Munro wrote:
> >
> > I had been planning to commit v14 this morning but got cold feet with
> > the BMR-based interface. Heikki didn't like it much, and in the end,
> > neither did I. I
On Sun, Apr 7, 2024 at 3:57 PM Melanie Plageman
wrote:
>
> On Thu, Apr 04, 2024 at 02:03:30PM +0300, Nazir Bilal Yavuz wrote:
> >
> > On Wed, 3 Apr 2024 at 23:44, Melanie Plageman
> > wrote:
> > >
> > > I don't see the point of BlockSampler_HasMore() anymore. I removed it in
> > > the attached
On 4/7/24 22:35, Tomas Vondra wrote:
> On 4/7/24 14:37, David Rowley wrote:
>> On Sun, 7 Apr 2024 at 22:05, John Naylor wrote:
>>>
>>> On Sat, Apr 6, 2024 at 7:37 PM David Rowley wrote:
>>> I'm planning on pushing these, pending a final look at 0002 and 0003
on Sunday morning NZ
Hi,
Sorry, without any connection with the technical part of the thread.
But I couldn't help but record this, and congratulate Andres Freund, for
the excellent work.
It's not every day that a big press, in Brazil or around the world,
publishes something related to technology people.
Today I came
On 4/7/24 14:37, David Rowley wrote:
> On Sun, 7 Apr 2024 at 22:05, John Naylor wrote:
>>
>> On Sat, Apr 6, 2024 at 7:37 PM David Rowley wrote:
>>>
>> I'm planning on pushing these, pending a final look at 0002 and 0003
>>> on Sunday morning NZ time (UTC+12), likely in about 10 hours time.
>>
Corey Huinker writes:
>> I've also used the technique quite a lot, but only using the PK,
>> didn't know about the ctid trick, so many thanks for documenting it.
> tid-scans only became a thing a few versions ago (12?). Prior to that, PK
> was the only way to go.
I think we had TID scans for
On Thu, Apr 04, 2024 at 02:03:30PM +0300, Nazir Bilal Yavuz wrote:
>
> On Wed, 3 Apr 2024 at 23:44, Melanie Plageman
> wrote:
> >
> > I don't see the point of BlockSampler_HasMore() anymore. I removed it in
> > the attached and made BlockSampler_Next() return InvalidBlockNumber
> > under the
On 2024-04-07 18:13 +0200, David E. Wheeler wrote:
> A question about the behavior of the JSON Path parser. The docs[1]
> have this to say about numbers:
>
> > Numeric literals in SQL/JSON path expressions follow JavaScript
> > rules, which are different from both SQL and JSON in some minor
> >
On Sun, 2024-04-07 at 14:19 +0200, Alvaro Herrera wrote:
> I pushed the "copy" pointer now, except that I renamed it to
> "insert",
> which is what we call the operation being tracked. I also added some
> comments.
The "copy" pointer, as I called it, is not the same as the "insert"
pointer (as
"Daniel Verite" writes:
> Also the use of "and/or" in the previous version conveys the fact
> that operator class and ordering options are not mutually
> exclusive. But when using "any of the following" in the new text,
> doesn't it loose that meaning?
Yeah; and/or is perfectly fine here and
Hi, Alexander!
On Sun, 7 Apr 2024 at 12:34, Pavel Borisov wrote:
> Hi, Alexander!
>
> On Sun, 7 Apr 2024 at 07:33, Alexander Korotkov
> wrote:
>
>> Hi, Pavel!
>>
>> On Fri, Apr 5, 2024 at 6:58 PM Pavel Borisov
>> wrote:
>> > On Tue, 2 Apr 2024 at 19:17, Jeff Davis wrote:
>> >>
>> >> On Tue,
> On 7 Apr 2024, at 21:41, Alvaro Herrera wrote:
>
> Well, it would be nice to have *some* test, but as you say it is way
> more complex than the thing being tested, and it zooms in on the
> functioning of the multixact creation in insane quantum-physics ways ...
> to the point that you can
Hi,
On 2024-04-01 11:53:28 +0900, Masahiko Sawada wrote:
> On Fri, Mar 29, 2024 at 4:21 PM John Naylor wrote:
> > I've marked it Ready for Committer.
>
> Thank you! I've attached the patch that I'm going to push tomorrow.
Locally I ran a 32bit build with ubsan enabled (by accident actually),
Hi Alexander and Dmitry,
07.04.2024 01:22, Alexander Korotkov wrote:
I've pushed 0001 and 0002. I didn't push 0003 for the following reasons.
Please try the following (erroneous) query:
CREATE TABLE t1(i int, t text) PARTITION BY LIST (t);
CREATE TABLE t1pa PARTITION OF t1 FOR VALUES IN
Laurenz Albe writes:
> Patch v3 is attached.
I agree with documenting this hazard, but I think it'd be better
to do so in the "Triggers" chapter. There is no hazard unless
you are writing user-defined triggers, which is surely far fewer
people than use foreign keys. So I suggest something like
On 2024-Feb-03, Andrey M. Borodin wrote:
> Here's the test draft. This test reliably reproduces sleep on CV when waiting
> next multixact to be filled into "members" SLRU.
> Cost of having this test:
> 1. We need a new injection point type "wait" (in addition to "error" and
> "notice"). It
On Sun, Apr 7, 2024 at 1:33 PM Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Tue, 2 Apr 2024 at 11:40, Thomas Munro wrote:
> >
> > I had been planning to commit v14 this morning but got cold feet with
> > the BMR-based interface. Heikki didn't like it much, and in the end,
> > neither did I. I have
On 4/7/24 19:46, Tomas Vondra wrote:
> On 4/5/24 21:43, Tomas Vondra wrote:
>> Hi,
>>
>> ...
>>
>> 2) The prefetching is not a huge improvement, at least not for these
>> three filesystems (btrfs, ext4, xfs). From the color scale it might seem
>> like it helps, but those values are relative to the
Hi,
On Tue, 2 Apr 2024 at 11:40, Thomas Munro wrote:
>
> I had been planning to commit v14 this morning but got cold feet with
> the BMR-based interface. Heikki didn't like it much, and in the end,
> neither did I. I have now removed it, and it seems much better. No
> other significant
On 07/04/2024 13:19, Heikki Linnakangas wrote:
1st patch fixes the LDAP setup tests, and 2nd patch fixes the error
handling in the END blocks.
Committed and backpatched these test fixes.
--
Heikki Linnakangas
Neon (https://neon.tech)
On Sun, Apr 7, 2024 at 1:00 PM Alexander Lakhin wrote:
> Please look at an assertion failure (reproduced starting from 5bf748b86),
> triggered by the following query:
> CREATE TABLE t (a int, b int);
> CREATE INDEX t_idx ON t (a, b);
> INSERT INTO t (a, b) SELECT g, g FROM generate_series(0, 999)
On 2024-04-07 18:51:40 +0200, Daniel Gustafsson wrote:
> > On 7 Apr 2024, at 18:28, Andres Freund wrote:
> >
> > On 2024-04-07 16:52:05 +0200, Daniel Gustafsson wrote:
> >>> On 7 Apr 2024, at 14:51, Andrew Dunstan wrote:
> >>> On 2024-04-06 Sa 20:49, Andres Freund wrote:
> >>
> That's
Hello Peter,
03.04.2024 22:53, Peter Geoghegan wrote:
On Mon, Apr 1, 2024 at 6:33 PM Peter Geoghegan wrote:
Note: v18 doesn't have any adjustments to the costing, as originally
planned. I'll probably need to post a revised patch with improved (or
at least polished) costing in the next few
> On 7 Apr 2024, at 18:28, Andres Freund wrote:
>
> On 2024-04-07 16:52:05 +0200, Daniel Gustafsson wrote:
>>> On 7 Apr 2024, at 14:51, Andrew Dunstan wrote:
>>> On 2024-04-06 Sa 20:49, Andres Freund wrote:
>>
That's probably unnecessary optimization, but it seems a tad silly to read
On Sun, Apr 7, 2024 at 9:36 PM Amit Langote wrote:
>
>
> 0002 needs an expanded commit message but I've run out of energy today.
>
some cosmetic issues in v51, 0002.
in struct JsonTablePathScan,
/* ERROR/EMPTY ON ERROR behavior */
bool errorOnError;
the comments seem not right.
I think
On 2024-04-07 16:52:05 +0200, Daniel Gustafsson wrote:
> > On 7 Apr 2024, at 14:51, Andrew Dunstan wrote:
> > On 2024-04-06 Sa 20:49, Andres Freund wrote:
>
> >> That's probably unnecessary optimization, but it seems a tad silly to read
> >> an
> >> entire, potentially sizable, file to just use
Hello Hackers,
A question about the behavior of the JSON Path parser. The docs[1] have this to
say about numbers:
> Numeric literals in SQL/JSON path expressions follow JavaScript rules, which
> are different from both SQL and JSON in some minor details. For example,
> SQL/JSON path allows
1 - 100 of 129 matches
Mail list logo
