> On 3 Jan 2024, at 15:15, Pavel Borisov wrote:
>
> Hi and Happy New Year!
>
> I've looked through the patches and the change seems quite small and
> justified. But at the second round, some doubt arises on whether this long
> patchset indeed introduces enough performance gain? I may be
> On 15 Mar 2024, at 17:12, Nazir Bilal Yavuz wrote:
>
> I did not have the time to check other things you mentioned but I
> tested the read performance. The table size is 5.5GB, I did 20 runs in
> total.
Hi Nazir!
Do you plan to review anything else? Or do you think it worth to look at by
On Sun, Apr 7, 2024 at 11:49 AM Andres Freund wrote:
>
> Hi,
>
> On 2024-01-22 13:01:31 +0700, John Naylor wrote:
> > On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> > > And 397->320ms
> > > for something as core as this, is imo worth considering on its own.
> >
> > Hi Andres, this
Hi,
On 2024-01-22 13:01:31 +0700, John Naylor wrote:
> On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> > And 397->320ms
> > for something as core as this, is imo worth considering on its own.
>
> Hi Andres, this interesting work seems to have fallen off the radar --
> are you still
Erik Wienhold writes:
> On 2024-04-06 20:14 +0200, Michal Bartak wrote:
>> The issue described bellow exists in postgresql ver 16.2 (found in some
>> previous major versions)
> Can confirm also on master.
I'm sure it's been there a while :-(
> I'm surprised that the comment is not skipped by
hi.
about v50.
+/*
+ * JsonTableSiblingJoin -
+ * Plan to union-join rows of nested paths of the same level
+ */
+typedef struct JsonTableSiblingJoin
+{
+ JsonTablePlan plan;
+
+ JsonTablePlan *lplan;
+ JsonTablePlan *rplan;
+} JsonTableSiblingJoin;
"Plan to union-join rows of nested paths of the
On Sun, Apr 07, 2024 at 02:27:43AM +0200, Tomas Vondra wrote:
> On 4/6/24 23:34, Melanie Plageman wrote:
> > ...
> >>
> >> I realized it makes more sense to add a FIXME (I used XXX. I'm not when
> >> to use what) with a link to the message where Andres describes why he
> >> thinks it is a bug. If
Bruce Momjian writes:
> On Sun, Apr 7, 2024 at 12:00:25AM +0200, Daniel Verite wrote:
>> Agreed we don't want to document that, but also why doesn't \. in the
>> contents represent just a dot (as opposed to being an error),
>> just like \a is a?
> I looked into this and started to realize that
On Sat, Apr 06, 2024 at 02:41:01PM -0500, Nathan Bossart wrote:
> Here is what I have staged for commit, which I intend to do shortly.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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, 2024-04-02 at 11:49 +0300, Alexander Korotkov wrote:
>> > I don't like the idea that every custom table AM reltoptions should
>> > begin with StdRdOptions. I would
On Sun, Apr 7, 2024 at 12:00:25AM +0200, Daniel Verite wrote:
> Tom Lane wrote:
>
> > This is sufficiently weird that I'm starting to come around to
> > Daniel's original proposal that we just drop the server's recognition
> > of \. altogether (which would allow removal of some dozens of
On Mon, Apr 1, 2024 at 9:54 AM Masahiko Sawada wrote:
>
> Thank you! I've attached the patch that I'm going to push tomorrow.
Excellent!
I've attached a mostly-polished update on runtime embeddable values,
storing up to 3 offsets in the child pointer (1 on 32-bit platforms).
As discussed, this
On Tue, Jan 30, 2024 at 4:13 AM Ants Aasma wrote:
>
> But given that we know the data length and we have it in a register
> already, it's easy enough to just mask out data past the end with a
> shift. See patch 1. Performance benefit is about 1.5x Measured on a
> small test harness that just
Hi,
On 2024-04-07 00:45:31 +0200, Jelte Fennema-Nio wrote:
> On Sat, 6 Apr 2024 at 22:21, Andres Freund wrote:
> > The small regression for small results is still kinda visible, I haven't yet
> > tested the patch downthread.
>
> Thanks a lot for the faster test script, I'm also impatient. I
On Sat, Apr 6, 2024 at 9:25 PM Thomas Munro wrote:
>
> I found a bug in read_stream.c that could be hit with Melanie's
> streaming seq scan patch with parallelism enabled and certain buffer
> pool conditions. Short version: there is an edge case where an "if"
> needed to be a "while", or we
I found a bug in read_stream.c that could be hit with Melanie's
streaming seq scan patch with parallelism enabled and certain buffer
pool conditions. Short version: there is an edge case where an "if"
needed to be a "while", or we could lose a few blocks. Here's the fix
for that, longer
So what was really bothering me about this patchset was that I
didn't think marginal performance gains were a sufficient reason
to put a whole different operating mode into libpq. However,
I've reconsidered after realizing that implementing FETCH_COUNT
atop traditional single-row mode would
Hi,
On 2024-04-07 00:19:35 +0200, Daniel Gustafsson wrote:
> > On 6 Apr 2024, at 23:44, Andres Freund wrote:
>
> > It might be useful to print a few lines, but the whole log files can be
> > several megabytes worth of output.
>
> The non-context aware fix would be to just print the last 1024
On Sun, 7 Apr 2024, 01:59 David Rowley, wrote:
> On Sun, 7 Apr 2024 at 05:45, Matthias van de Meent
> wrote:
> > Malloc's docs specify the minimum chunk size at 4*sizeof(void*) and
> itself uses , so using powers of 2 for chunks would indeed fail to detect
> 1s in the 4th bit. I suspect you'll
On 4/6/24 23:34, Melanie Plageman wrote:
> ...
>>
>> I realized it makes more sense to add a FIXME (I used XXX. I'm not when
>> to use what) with a link to the message where Andres describes why he
>> thinks it is a bug. If we plan on fixing it, it is good to have a record
>> of that. And it makes
On Sun, 7 Apr 2024 at 05:45, Matthias van de Meent
wrote:
> Malloc's docs specify the minimum chunk size at 4*sizeof(void*) and itself
> uses , so using powers of 2 for chunks would indeed fail to detect 1s in the
> 4th bit. I suspect you'll get different results when you check the allocation
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
festooned it with warnings about why exactly it's inherently
On Sat, 6 Apr 2024 at 22:21, Andres Freund wrote:
> The small regression for small results is still kinda visible, I haven't yet
> tested the patch downthread.
Thanks a lot for the faster test script, I'm also impatient. I still
saw the small regression with David his patch. Here's a v6 where I
Hi, Alexander!
I didn't push 0003 for the following reasons.
Thanks for clarifying. You are right, these are serious reasons.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
Hi, Dmitry!
On Fri, Apr 5, 2024 at 4:00 PM Dmitry Koval wrote:
> > I've revised the patchset.
>
> Thanks for the corrections (especially ddl.sgml).
> Could you also look at a small optimization for the MERGE PARTITIONS
> command (in a separate file
>
> On 6 Apr 2024, at 23:44, Andres Freund wrote:
> It might be useful to print a few lines, but the whole log files can be
> several megabytes worth of output.
The non-context aware fix would be to just print the last 1024 (or something)
bytes from the logfile:
diff --git
On Fri, 5 Apr 2024 at 18:48, Robert Haas wrote:
> Maybe we'd be better off adding a libpq connection
> option that forces the use of a specific minor protocol version, but
> then we'll need backward-compatibility code in libpq basically
> forever. But maybe we need that anyway to avoid older and
Tom Lane wrote:
> This is sufficiently weird that I'm starting to come around to
> Daniel's original proposal that we just drop the server's recognition
> of \. altogether (which would allow removal of some dozens of lines of
> complicated and now known-buggy code)
FWIW my plan was to
For every complex problem there is an answer that is clear, simple, and wrong.
Since the RFC allows microsecond timestamp granularity, the first thing that
comes to everyone's mind is to insert microsecond granularity into UUIDv7. And
if the RFC allowed nanosecond timestamp granularity, then
Hi, Alvaro!
Thank you for your care on this matter.
On Fri, Apr 5, 2024 at 9:15 PM Alvaro Herrera wrote:
> BTW I noticed that
> https://coverage.postgresql.org/src/backend/commands/waitlsn.c.gcov.html
> says that lsn_cmp is not covered by the tests. This probably indicates
> that the tests are
Hi,
I recently started to be bothered by regress_* logs after some kinds of test
failures containing the whole log of a test failure. E.g. in
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus=2024-04-06%2016%3A28%3A38
...
### Restarting node "standby"
# Running: pg_ctl -w -D
Hi,
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 patches, so I marked the CF
> entry corresponding to this work as
Hi,
On Fri, 5 Apr 2024 at 03:28, Melih Mutlu
wrote:
>Right. It was a mistake, forgot to remove that. Fixed it in v5.
If you don't mind, I have some suggestions for patch v5.
1. Shouldn't PqSendBufferSize be of type size_t?
There are several comparisons with other size_t variables.
static
>
>
>
> I think it'll be a serious, serious error for this not to be
> SECTION_DATA. Maybe POST_DATA is OK, but even that seems like
> an implementation compromise not "the way it ought to be".
>
We'd have to split them on account of when the underlying object is
created. Index statistics would
On 2024-04-06 20:14 +0200, Michal Bartak wrote:
> The issue described bellow exists in postgresql ver 16.2 (found in some
> previous major versions)
Can confirm also on master.
> The documentation defines a comment as:
>
> > A comment is a sequence of characters beginning with double dashes and
Hi,
On 2024-04-06 14:34:17 +1300, David Rowley wrote:
> I don't see any issues with v5, so based on the performance numbers
> shown on this thread for the latest patch, it would make sense to push
> it. The problem is, I just can't recreate the performance numbers.
>
> I've tried both on my AMD
On Sat, Apr 06, 2024 at 02:51:39PM +1300, David Rowley wrote:
> On Sat, 6 Apr 2024 at 14:17, Nathan Bossart wrote:
>> On Sat, Apr 06, 2024 at 12:08:14PM +1300, David Rowley wrote:
>> > Won't Valgrind complain about this?
>> >
>> > +pg_popcount_avx512(const char *buf, int bytes)
>> >
>> > + buf =
Hello all
The issue described bellow exists in postgresql ver 16.2 (found in some
previous major versions)
The documentation defines a comment as:
> A comment is a sequence of characters beginning with double dashes and
> extending to the end of the line
When using such a comment within CASE
> On 6 Apr 2024, at 16:04, Tom Lane wrote:
> Daniel Gustafsson writes:
>>> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>>> Why do we need to check for the versions at all? We should just check for
>>> the functions we need. At least that's always been the normal approach in
>>>
On Sat, 2024-04-06 at 18:13 +0200, Alvaro Herrera wrote:
> my understanding of pg_atomic_compare_exchange_u64 is that
> *expected is set to the value that's stored in *ptr prior to the
> exchange.
Sorry, my mistake. Your version looks good.
Regards,
Jeff Davis
On Sat, 6 Apr 2024, 14:36 David Rowley, wrote:
> On Sat, 6 Apr 2024 at 02:30, Matthias van de Meent
> wrote:
> >
> > On Thu, 4 Apr 2024 at 22:43, Tom Lane wrote:
> > >
> > > Matthias van de Meent writes:
> > > > It extends memory context IDs to 5 bits (32 values), of which
> > > > - 8 have
I wrote:
> So the current behavior is that \. that is on the end of a line,
> but is not the whole line, is silently discarded and we keep going.
> All versions throw "end-of-copy marker corrupt" if there is
> something after \. on the same line.
> This is sufficiently weird that I'm starting to
Hi,
On Sat, Apr 06, 2024 at 10:13:00AM +0530, Amit Kapila wrote:
> On Fri, Apr 5, 2024 at 8:05 PM Bertrand Drouvot
> wrote:
>
> I think the new LSN can be visible only when the corresponding WAL is
> written by XLogWrite(). I don't know what in XLogSetAsyncXactLSN() can
> make it visible. In
On 2024-Apr-05, Jeff Davis wrote:
> Minor comments:
> * Also, I assume that the Max() call in
> pg_atomic_monotonic_advance_u64() is just for clarity? Surely the
> currval cannot be less than _target when it returns. I'd probably just
> do Assert(currval >= _target) and then return currval.
Uhh
On Sat, Apr 06, 2024 at 04:57:51PM +0200, Tomas Vondra wrote:
> On 4/6/24 15:40, Melanie Plageman wrote:
> > On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
> >>
> >>
> >> On 4/6/24 01:53, Melanie Plageman wrote:
> >>> On Fri, Apr 05, 2024 at 04:06:34AM -0400, Melanie Plageman wrote:
Hi,
On Sat, Apr 6, 2024 at 3:55 PM jian he wrote:
> On Sat, Apr 6, 2024 at 2:03 PM Amit Langote wrote:
> >
> > >
> > > * problem with type "char". the view def output is not the same as
> > > the select * from v1.
> > >
> > > create or replace view v1 as
> > > SELECT col FROM s,
> > >
Melanie Plageman writes:
> On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
>> * The one question I'm somewhat unsure about is why Tom chose to use the
>> "wrong" recheck flag in the 2017 commit, when the correct recheck flag
>> is readily available. Surely that had a reason, right?
On 4/6/24 15:40, Melanie Plageman wrote:
> On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
>>
>>
>> On 4/6/24 01:53, Melanie Plageman wrote:
>>> On Fri, Apr 05, 2024 at 04:06:34AM -0400, Melanie Plageman wrote:
On Thu, Apr 04, 2024 at 04:35:45PM +0200, Tomas Vondra wrote:
>
On 4/6/24 02:51, Tomas Vondra wrote:
>
> * The one question I'm somewhat unsure about is why Tom chose to use the
> "wrong" recheck flag in the 2017 commit, when the correct recheck flag
> is readily available. Surely that had a reason, right? But I can't think
> of one ...
>
I've been
On Fri, Apr 5, 2024 at 8:35 PM Amit Langote wrote:
>
> On Thu, Apr 4, 2024 at 9:02 PM Amit Langote wrote:
> > I'll post the rebased 0002 tomorrow after addressing your comments.
>
> Here's one. Main changes:
>
> * Fixed a bug in get_table_json_columns() which caused nested columns
> to be
Daniel Gustafsson writes:
>> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>> Why do we need to check for the versions at all? We should just check for
>> the functions we need. At least that's always been the normal approach in
>> configure.
> We could, but finding a stable set of
On Sat, Apr 06, 2024 at 02:51:45AM +0200, Tomas Vondra wrote:
>
>
> On 4/6/24 01:53, Melanie Plageman wrote:
> > On Fri, Apr 05, 2024 at 04:06:34AM -0400, Melanie Plageman wrote:
> >> On Thu, Apr 04, 2024 at 04:35:45PM +0200, Tomas Vondra wrote:
> >>> On 4/4/24 00:57, Melanie Plageman wrote:
>
On Sat, 6 Apr 2024 at 23:17, Jelte Fennema-Nio wrote:
> Weird that on your machines you don't see a difference. Are you sure
> you didn't make a silly mistake, like not restarting postgres or
> something?
I'm sure. I spent quite a long time between the AMD and an Apple m2 trying.
I did see the
On Sat, Apr 6, 2024 at 12:18 PM Amit Kapila wrote:
>
> Why the handling w.r.t active_pid in InvalidatePossiblyInactiveSlot()
> is not similar to InvalidatePossiblyObsoleteSlot(). Won't we need to
> ensure that there is no other active slot user? Is it sufficient to
> check inactive_since for the
> On 29 Feb 2024, at 06:59, Kyotaro Horiguchi wrote:
>
> At Sat, 3 Feb 2024 22:32:45 +0500, "Andrey M. Borodin"
> wrote in
>> Here's the test draft. This test reliably reproduces sleep on CV when
>> waiting next multixact to be filled into "members" SLRU.
>
> By the way, I raised a
On Sat, 6 Apr 2024 at 03:34, David Rowley wrote:
> Does anyone else want to try the attached script on the v5 patch to
> see if their numbers are better?
On my machine (i9-10900X, in Ubuntu 22.04 on WSL on Windows) v5
consistently beats master by ~0.25 seconds:
master:
Run 100 100 500:
> On 6 Apr 2024, at 01:10, Tom Lane wrote:
> (So now I'm wondering why *only* copperhead has shown this so far.
> Are our other cross-version-upgrade testing animals AWOL?)
Clicking around searching for Xversion animals I didn't spot any, but without
access to the database it's nontrivial to
> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>
> On 05.04.24 23:48, Daniel Gustafsson wrote:
>> The reason to expand the check is to ensure that we have the version we want
>> for both OpenSSL and LibreSSL, and deprecating OpenSSL versions isn't all
>> that
>> commonly done so having to
On Sat, Apr 6, 2024 at 2:03 PM Amit Langote wrote:
>
> >
> > * problem with type "char". the view def output is not the same as
> > the select * from v1.
> >
> > create or replace view v1 as
> > SELECT col FROM s,
> > JSON_TABLE(jsonb '{"d": ["hello", "hello1"]}', '$' as c1
> > COLUMNS(col
On Fri, Apr 5, 2024 at 10:31 AM shveta malik wrote:
>
> Please find v2. Changes are:
Thanks for the patch. Here are some comments.
1. Can we have a clear saying in the shmem variable who's syncing at
the moment? Is it a slot sync worker or a backend via SQL function?
Perhaps turn "bool
On Sat, Apr 6, 2024 at 11:55 AM Bharath Rupireddy
wrote:
>
Why the handling w.r.t active_pid in InvalidatePossiblyInactiveSlot()
is not similar to InvalidatePossiblyObsoleteSlot(). Won't we need to
ensure that there is no other active slot user? Is it sufficient to
check inactive_since for the
On Sat, Apr 6, 2024 at 9:21 AM Thomas Munro wrote:
>
> On Sat, Apr 6, 2024 at 6:55 AM Alvaro Herrera wrote:
> > Pushed 0001.
>
> Could that be related to the 3 failures on parula that look like this?
>
> TRAP: failed Assert("node->next == 0 && node->prev == 0"), File:
>
On Fri, Apr 5, 2024 at 1:14 PM Bertrand Drouvot
wrote:
>
> > Please find the attached v36 patch.
>
> A few comments:
>
> 1 ===
>
> +
> +The timeout is measured from the time since the slot has become
> +inactive (known from its
> +inactive_since value) until it gets
On Fri, Apr 5, 2024 at 10:31 AM shveta malik wrote:
>
> Please find v2. Changes are:
> 1) Rebased the patch as there was conflict due to recent commit 6f132ed.
> 2) Added an Assert in update_synced_slots_inactive_since() to ensure
> that the slot does not have active_pid.
> 3) Improved commit msg
On Sat, Apr 6, 2024 at 12:31 PM jian he wrote:
> On Fri, Apr 5, 2024 at 8:35 PM Amit Langote wrote:
> > Here's one. Main changes:
> >
> > * Fixed a bug in get_table_json_columns() which caused nested columns
> > to be deparsed incorrectly, something Jian reported upthread.
> > * Simplified the
On 05.04.24 23:48, Daniel Gustafsson wrote:
The reason to expand the check is to ensure that we have the version we want
for both OpenSSL and LibreSSL, and deprecating OpenSSL versions isn't all that
commonly done so having to change the version in the check didn't seem that
invasive to me.
66 matches
Mail list logo
