Hi hackers!
My colleague gave me an interesting case related to min max
optimization. Adding a useless left join to the select min from t query
breaks the min/max read optimization from the index.
What is meant is shown in the example below:
drop table if exists t1;
drop table if exists t2;
> On Tue, Feb 25, 2025 at 10:52:05AM GMT, Dmitry Dolgov wrote:
> > On Fri, Oct 18, 2024 at 09:21:19PM GMT, Dmitry Dolgov wrote:
> > TL;DR A PoC for changing shared_buffers without PostgreSQL restart, via
> > changing shared memory mapping layout. Any feedback is appreciated.
>
> Hi,
>
> Here is a n
On Wed, Feb 26, 2025 at 4:48 PM vignesh C wrote:
>
> On Wed, 26 Feb 2025 at 14:35, Amit Kapila wrote:
> >
> > How about changing it slightly as follows to make it clear: "If
> > -doption is not provided, the database name will be
> > obtained from -P. If the database name is not
> > specified in
On Monday, February 24, 2025 5:50 PM Amit Kapila
wrote:
>
> On Wed, Dec 11, 2024 at 12:37 PM Masahiko Sawada
> wrote:
> >
> > I confirmed that the proposed patch fixes these issues. I have one
> > question about the patch:
> >
> > In the main loop in SnapBuildDistributeSnapshotAndInval(), we ha
On Wed, Feb 26, 2025 at 7:18 PM Amit Kapila wrote:
>
> On Wed, Feb 26, 2025 at 5:40 PM Nisha Moond wrote:
> >
> > Attached the patch v1 fixing this issue.
> >
> > Issue reported by: Hou Zhijie.
> >
>
> Thanks for the report and patch. I'll look into it.
>
Pushed the patch with a slightly differe
On Thu, Feb 27, 2025 at 10:47 AM Masahiko Sawada wrote:
>
> On Tue, Feb 25, 2025 at 7:33 PM Amit Kapila wrote:
> >
> > AFAICU, InvalidateObsoleteReplicationSlots() is not serialized with
> > this operation. So, isn't it possible that the source slot exists at
> > the later position in Replication
Hi Jakub,
On Wed, Feb 26, 2025 at 09:48:41AM +0100, Jakub Wartak wrote:
> On Mon, Feb 24, 2025 at 5:11 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Mon, Feb 24, 2025 at 09:06:20AM -0500, Andres Freund wrote:
> > > Does the issue with "new" backends seeing pages as not present exist both
>
On Wed, Feb 26, 2025 at 6:13 PM Bertrand Drouvot
wrote:
[..]
> > Meanwhile v5 is attached with slight changes to try to make cfbot happy:
>
> Thanks for the updated version!
>
> FWIW, I had to do a few changes to get an error free compiling experience with
> autoconf/or meson and both with or with
Em qui., 27 de fev. de 2025 às 02:08, Michael Paquier
escreveu:
> On Wed, Feb 26, 2025 at 07:04:25PM +0530, vignesh C wrote:
> > On Tue, 18 Feb 2025 at 18:18, Ranier Vilela wrote:
> >> Similar to commit 5b94e27 [1]
> >> The correct function when freeing memory in the frontend,
> >> using the fun
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi Ivan Kush
I tested the patch with `commands.sql` and obser
On 2025-Feb-27, Amul Sul wrote:
> Attached is the rebased patch set against the latest master head,
> which also includes a *new* refactoring patch (0001). In this patch,
> I’ve re-added ATExecAlterChildConstr(), which is required for the main
> feature patch (0008) to handle recursion from differ
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi Joel,
After testing the patch, I observed that for single-
Pavel Stehule писал(а) 2025-02-26 22:34:
hI
I can confirm 60% speedup for execution of function fx and fx3 - both
functions are very primitive, so for real code the benefit can be
higher
Unfortunately, there is about 5% slowdown for inlined code, and for
just plpgsql code too.
I tested fx4
cr
Thanks Vignesh for the review!
> Currently we are supporting only PG13 and higher versions.
I understand that servers older than PG13 are no longer supported. But on
the client side, we still have this notice at the top of describe.c file,
which indicates that the client should support 9.2+.
*
On 2025-02-27 Th 12:16 AM, Michael Paquier wrote:
On Mon, Feb 03, 2025 at 12:22:52PM +0100, Peter Eisentraut wrote:
CF 2025-01 has just ended, so I suggest that everyone try this now. We can
check in perhaps two weeks whether this results in lots of stuff falling
through the cracks or still t
čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov <
a.pyha...@postgrespro.ru> napsal:
> Pavel Stehule писал(а) 2025-02-26 22:34:
> > hI
> >
> > I can confirm 60% speedup for execution of function fx and fx3 - both
> > functions are very primitive, so for real code the benefit can be
> > higher
>
Hi,
We use EXTRA_REGRESS_OPTS to make sure the whole test suite passes with
our extension loaded and since I prefer develop in meson over using
autotools and make the lack of support for EXTRA_REGRESS_OPTS in meson
has bugged me for a while.
I have implemented support for it as an environment
Hi,
On 2025-02-27 13:53:17 +0100, Andreas Karlsson wrote:
> We use EXTRA_REGRESS_OPTS to make sure the whole test suite passes with our
> extension loaded and since I prefer develop in meson over using autotools
> and make the lack of support for EXTRA_REGRESS_OPTS in meson
> has bugged me for a w
Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier
escreveu:
> On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> > @@ -455,7 +455,9 @@ set_locale_and_encoding(void)
> > locale->db_locale,
> > strlen(locale->db_locale));
> > else
> > - datlocale_literal = pg_strdup("NULL");
> On 24 Feb 2025, at 22:51, Jacob Champion
> wrote:
>
> On Wed, Feb 19, 2025 at 3:13 PM Daniel Gustafsson wrote:
>> Are there any blockers for getting this in?
>
>> + SSL_context = ssl_init_context(isServerStart, host);
>
> I'm still not quite following the rationale behind the SSL_
On Mon, Nov 18, 2024 at 10:07 AM Jim Jones
wrote:
> 2024-11-18 16:00:42.720 CET [3135117] -> 192.168.178.27 STATEMENT:
> ...
> 2024-11-18 16:01:23.273 CET [3114980] -> [local] LOG: received SIGHUP,
> ...
2024-11-18 16:01:46.769 CET [3114981] -> [local] LOG: checkpoint
> Is it supposed to be li
On Thu, Feb 27, 2025 at 07:47:09AM +, Bertrand Drouvot wrote:
> That's how I did it initially but decided to move it to pgstat_backend.c. The
> reason was that it's fully linked to "per backend" stats and that there is
> no SQL api on top of it (while I think that's the case for almost all the
On Tue, Feb 18, 2025 at 01:56:09PM -0600, Nathan Bossart wrote:
> On Mon, Jan 27, 2025 at 03:38:39PM -0500, Robert Haas wrote:
>> Also, how sure are we that turning this off globally is a solid idea?
>> Off-hand, it doesn't sound that bad: there are probably situations in
>> which autovacuum never
On Fri, Feb 28, 2025 at 11:58 AM Melanie Plageman
wrote:
> On Thu, Feb 27, 2025 at 1:08 PM Tom Lane wrote:
> > I wonder if it'd be a good idea to add something like
> >
> > Assert(stream->distance == 1);
> > Assert(stream->pending_read_nblocks == 0);
> >
On Fri, Feb 28, 2025 at 2:29 PM Thomas Munro wrote:
> On Fri, Feb 28, 2025 at 11:58 AM Melanie Plageman
> wrote:
> > On Thu, Feb 27, 2025 at 1:08 PM Tom Lane wrote:
> > > I wonder if it'd be a good idea to add something like
> > >
> > > Assert(stream->distance == 1);
> > >
Hi,
On Thu, Feb 27, 2025 at 05:55:19PM -0500, Melanie Plageman wrote:
> On Thu, Feb 27, 2025 at 11:30 AM Andres Freund wrote:
> >
> > On 2025-02-27 11:08:04 -0500, Melanie Plageman wrote:
> >
> > > However, since that is a bigger project (with more refactoring, etc),
> > > he suggested that we ch
> For now, I think it makes sense to keep postgres_fdw_get_connections()
> aligned with the current implementation. Otherwise, explaining what
> remote_backend_pid = NULL means could be confusing, especially since
> pipeline mode isn't supported yet in postgres_fdw.
Make sense. I have created a pa
Attached a v6 with O_NOFOLLOW removed, I noticed that it failed on
windows. Please let me know if I should do this in any other way that
is portable across platforms.
Thanks
On Thu, Feb 27, 2025 at 11:39 PM Abhishek Chanda
wrote:
>
> Thanks for the review, Daniel. Please find v5 of this patch at
On Thu, 2025-02-27 at 21:35 -0600, Nathan Bossart wrote:
> I spent some time on this one today. A couple of notes:
>
> * Since the reloption is a Boolean, there isn't a good way to tell whether
> it is actually set for the table or if it just inherited the default
> value. This is important
On Fri, Feb 28, 2025 at 5:10 AM Masahiko Sawada wrote:
>
> On Thu, Feb 27, 2025 at 12:52 AM Amit Kapila wrote:
> >
> > On Thu, Feb 27, 2025 at 10:47 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Feb 25, 2025 at 7:33 PM Amit Kapila
> > > wrote:
> > > >
> > > > AFAICU, InvalidateObsoleteRep
On Thu, Feb 27, 2025 at 4:48 PM Álvaro Herrera wrote:
>
> On 2025-Feb-27, Amul Sul wrote:
>
> > Attached is the rebased patch set against the latest master head,
> > which also includes a *new* refactoring patch (0001). In this patch,
> > I’ve re-added ATExecAlterChildConstr(), which is required f
>
> +--- error: relation is wrong type
> +SELECT pg_catalog.pg_restore_relation_stats(
> +'relation', 0::oid,
> +'relpages', 17::integer,
> +'reltuples', 400.0::real,
> +'relallvisible', 4::integer);
>
> Why do you need to specify all the stats (relpages, reltuples,
Hi,
On Thu, Feb 27, 2025 at 11:14:56AM -0500, Andres Freund wrote:
> I don't think the timing overhead is a relevant factor here - compared to the
> fork of a new connection or performing authentication the cost of taking a few
> timestamps is neglegible. A timestamp costs 10s to 100s of cycles, a
On Thu, Feb 27, 2025 at 04:56:05PM +, Dave Page wrote:
> Per some brief discussion on the core list, the attached patch updates the
> licence preamble to more accurately reflect the use of Postgres vs.
> PostgreSQL (see https://www.postgresql.org/about/policies/project-name/ for
> background fr
On Thu, 13 Feb 2025 at 14:01, Jeff Davis wrote:
> Attached a new patchset that doesn't change the API for
> ExecCopySlotMinimalTuple(). Instead, I'm using
> ExecFetchSlotMinimalTuple(), which avoids the extra memcpy if the slot
> is TTSOpsMinimalTuple, which is what HashAgg uses. I separated out t
Hello hackers,
While reviewing Mark Dilger’s patch series "Index AM API cleanup" [1],
I noticed some unexpected plan diffs when running the xtree and treeb
test modules. Specifically, an additional Sort node appears on top of
an Index Only Scan, even when the index key and sort key are the same.
F
On Fri, Feb 28, 2025 at 12:23 AM Alexandra Wang
wrote:
> While reviewing Mark Dilger’s patch series "Index AM API cleanup" [1],
> I noticed some unexpected plan diffs when running the xtree and treeb
> test modules. Specifically, an additional Sort node appears on top of
> an Index Only Scan, even
Thanks for the review, Daniel. Please find v5 of this patch attached.
I tried to bump up the minimum OpenBSD version in installation.sgml,
do I need to add this anywhere else? Please let me know if this needs
anything else.
Thanks
On Thu, Feb 20, 2025 at 4:25 PM Daniel Gustafsson wrote:
>
> > On
Hi,
On Thu, Feb 27, 2025 at 11:08:04AM -0500, Melanie Plageman wrote:
> I was just talking to Andres off-list and he mentioned that the volume
> of log_connections messages added in recent releases can really be a
> problem for users. He said ideally we would emit one message which
> consolidated
On Wed, Feb 26, 2025 at 09:48:50AM +, Bertrand Drouvot wrote:
> Yeah I think that makes sense, done that way in the attached.
>
> Speaking about physical walsender, I moved the test to 001_stream_rep.pl
> instead
> (would also fail without the fix).
Hmm. I was doing some more checks with th
Dear Amit,
> I understand that we may not have a clear use case for this to work in
> single-user mode. But how will we define the boundary in similar
> cases? I mean, we should have some rule for such exposed functions,
> and it should be followed uniformly. Now, if one needs a bigger or
> comple
On Thu, Feb 27, 2025 at 1:29 PM Hayato Kuroda (Fujitsu)
wrote:
>
> >
> > Which other functions do we see similar restrictions? I checked
> > "sequence manipulation functions" (1), and "Transaction ID and
> > Snapshot Information Functions" (2) but couldn't see similar
> > restrictions.
> >
> > (1)
Alexandra Wang writes:
> I’ve attached a patch that removes this unnecessary Sort node for
> B-tree-compatible indexes.
This does not look right at all. You can't just ignore the opfamily
etc. while deciding whether two pathkeys represent the same sort
ordering, as you did in create_mergejoin_pl
Hi All,
Thank you so much for the feedback.
> I don't think "another extension might use it someday" makes a very strong
> case,
> particularly for something that requires a new dependency.
The x86-simdsort library is an optional dependency in Postgres. Also the new
list sort implementation
On Wed, Feb 26, 2025 at 01:48:47PM +0200, Alexander Korotkov wrote:
> Thank you for offering the help. Updated version of patch is attached
> (I've added one memory barrier there just in case). I would
> appreciate if you could run it on batta, hachi or similar hardware.
Doing a revert of the re
On Thu, Dec 19, 2024 at 8:29 AM Robert Haas wrote:
> Cool. I don't want to commit this right before my vacation but I'll
> look into it in the new year if nobody beats me to it.
Nobody has beaten me to it, but I thought of one potential issue.
Suppose that somebody has a foreign table that exists
On Mon, Feb 17, 2025 at 5:44 PM Peter Geoghegan wrote:
> I need more feedback about this. I don't understand your perspective here.
>
> If I commit the skip scan patch, but don't have something like this
> instrumentation in place, it seems quite likely that users will
> complain about how opaque
Hi John,
Going back to your earlier comment:
> > > I'm not a fan of exposing these architecture-specific details to
> > > places that consult the capabilities. That requires things like
+#define PGCPUCAP_CRC32C pg_cpu_have(PG_CPU_FEATURE_SSE42)
> > Isn't that one thing currently pg_cpu_have(FE
On Thu, Feb 27, 2025 at 1:26 PM Andy Alsup wrote:
>
> I've submitted it for the up-coming commitfest. The link is:
> https://commitfest.postgresql.org/patch/5604/
> Thanks for all your help in reviewing these changes.
Thank you for the patch!
Regarding the 0001 patch, I think we can put uuidv4(
On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> Yeah, I also think it would look good like this.
It's the least confusing option, indeed. I've reduced a bit the diffs
and done that down to v16 for the pg_upgrade part where this exists.
Double-checking the tree, it does not seem
On Thu, Feb 27, 2025 at 11:14 AM Tom Lane wrote:
> Robert Haas writes:
> > But let's not make the mistake of saying "we're not going to move
> > things automatically because we want to find out if the authors are
> > still interested" and then getting really concerned when some stuff
> > doesn't
Hi.
Em ter., 18 de fev. de 2025 às 11:31, Melanie Plageman <
melanieplage...@gmail.com> escreveu:
> On Sun, Feb 16, 2025 at 1:12 PM Tom Lane wrote:
> >
> > Thomas Munro writes:
> > > Thanks! It's green again.
> >
> > The security team's Coverity instance complained about this patch:
> >
> > **
Hi,
On 2025-02-27 14:32:28 -0300, Ranier Vilela wrote:
> Hi.
>
> Em ter., 18 de fev. de 2025 às 11:31, Melanie Plageman <
> melanieplage...@gmail.com> escreveu:
>
> > On Sun, Feb 16, 2025 at 1:12 PM Tom Lane wrote:
> > >
> > > Thomas Munro writes:
> > > > Thanks! It's green again.
> > >
> > >
Hi,
On 2025-02-27 11:08:04 -0500, Melanie Plageman wrote:
> I was just talking to Andres off-list and he mentioned that the volume
> of log_connections messages added in recent releases can really be a
> problem for users.
For some added color: I've seen plenty systems where almost all the log vo
Hi,
On 2025-02-27 12:44:24 -0500, Andres Freund wrote:
> > CID 1592454: (#1 of 1): Explicit null dereferenced (FORWARD_NULL)
> > 8. var_deref_op: Dereferencing null pointer per_buffer_data.
>
> That's exactly what the messages you quoted are discussing, no?
Ah, no, it isn't. But I still think th
On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
wrote:
> Just some commit messages + few cleanups.
I'm worried about this:
+These longer pin lifetimes can cause buffer exhaustion with messages like "no
+unpinned buffers available" when the index has many pages that have similar
+ordering; but fu
I know I'm coming late to this, but I would like us to rethink having
statistics dumped by default. I was caught by this today, as I was doing
two dumps in a row, but the output changed between runs solely because the
stats got updated. It got me thinking about all the use cases of pg_dump
I've see
On Mon, Jan 27, 2025 at 1:55 AM Laurenz Albe wrote:
>
> On Thu, 2025-01-23 at 22:33 -0800, Gurjeet Singh wrote:
> > > > I am also wondering if having an autovacuum setting to control it would
> > > > be
> > > > a good idea for a feature.
> > >
> > > I'm all for that.
> >
> > Please see attached a
On Thu, Feb 27, 2025 at 10:01 PM Corey Huinker
wrote:
> +--- error: relation is wrong type
>> +SELECT pg_catalog.pg_restore_relation_stats(
>> +'relation', 0::oid,
>> +'relpages', 17::integer,
>> +'reltuples', 400.0::real,
>> +'relallvisible', 4::integer);
>>
>> Wh
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 27 Feb 2025 15:24:26 -0800,
Masahiko Sawada wrote:
> Pushed the 0001 patch.
Thanks!
> Regarding the 0002 patch, I realized we stopped exposing
> NextCopyFromRawFields() function:
>
> --- a/src/incl
On Feb 28, 2025 at 02:27 +0800, David G. Johnston ,
wrote:
> On Thu, Feb 6, 2025 at 8:04 AM Zhang Mingli wrote:
> > On Feb 6, 2025 at 10:49 +0800, David G. Johnston
> > , wrote:
> > >
> > > Yes, and when it does it is doing so in lieu of an error, and thus it is
> > > not returning the value of
On Thu, Feb 27, 2025 at 3:42 PM Robert Haas wrote:
> +1 for having some instrumentation. I do not agree with Tom that these
> are numbers that only Peter Geoghegan and 2-3 other people will ever
> understand. I grant that it's not going to make sense to everyone, but
> the number of people to whic
Masahiko,
I have combined the gen_random_uuid() and uuidv4() into a single row, as
you suggested. Please find the v5 patch, which has been squashed into a
single commit.
Best regards,
Andy Alsup
On Thu, Feb 27, 2025 at 5:02 PM Masahiko Sawada
wrote:
> On Thu, Feb 27, 2025 at 1:26 PM Andy Alsup
On Sat, 22 Feb 2025 at 03:51, Mark Dilger wrote:
>
>
>
> > On Feb 21, 2025, at 12:50 PM, Mark Dilger
> > wrote:
> >
> > Could one of the patch authors take a look?
>
> I turned the TAP test which triggers the error into a regression test that
> does likewise, for ease of stepping through the te
Hi
čt 27. 2. 2025 v 21:45 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
> >> So taken together, our results are all over the map, anywhere
> >> from 7% speedup to 7% slowdown. My usual rule of thumb is that
>
> > Where do you see 7%
On Tue, 2025-02-25 at 11:11 +0530, Ashutosh Bapat wrote:
> So the dumped statistics are not restored exactly. The reason for
> this
> is the table statistics is dumped before dumping ALTER TABLE ... ADD
> CONSTRAINT command which changes the statistics. I think all the
> pg_restore_relation_stats()
I've submitted it for the up-coming commitfest. The link is:
https://commitfest.postgresql.org/patch/5604/
Thanks for all your help in reviewing these changes.
Best Regards,
Andy Alsup
On Thu, Feb 27, 2025 at 1:58 PM Laurenz Albe
wrote:
> On Wed, 2025-02-26 at 22:11 -0500, Andy Alsup wrote:
> >
Robert Haas writes:
> OK, here is v2. One slightly unfortunate thing about this is that we
> end up with a line that is over 80 characters:
> extern DestReceiver *CreateExplainSerializeDestReceiver(struct
> ExplainState *es);
> Aside from perhaps shortening the function name, I don't see how to
On Fri, 28 Feb 2025 at 07:42, Jeff Davis wrote:
> https://www.postgresql.org/message-id/CAJVSvF6s1LgXF6KB2Cz68sHzk%2Bv%2BO_vmwEkaon%3DH8O9VcOr-tQ%40mail.gmail.com
>
> James pointed out something interesting, which is that a prepared
> statement enforces the work_mem limit at execution time, which
On Thu, Feb 27, 2025 at 4:12 PM Tom Lane wrote:
> +1, but how about explain_dr.h too? It doesn't seem though that
> we can avoid #include "executor/instrument.h" there, so it'd be
> a little asymmetrical. But the executor inclusion doesn't seem
> nearly as much almost-circular.
OK, here is v2.
On Thu, Feb 27, 2025 at 12:52 AM Amit Kapila wrote:
>
> On Thu, Feb 27, 2025 at 10:47 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Feb 25, 2025 at 7:33 PM Amit Kapila wrote:
> > >
> > > AFAICU, InvalidateObsoleteReplicationSlots() is not serialized with
> > > this operation. So, isn't it possibl
David Rowley writes:
> On Fri, 28 Feb 2025 at 07:42, Jeff Davis wrote:
>> My first reaction is that it's not right because the costing for the
>> plan is completely bogus with a different work_mem. It would make more
>> sense to me if we either (a) enforced work_mem as it was at the time of
>> pl
On Thu, 2025-02-27 at 17:04 -0500, Tom Lane wrote:
> Given that nobody's complained about this for twenty-plus years,
> I can't get excited about adding complexity to do either thing.
I had in mind some refactoring in this area, which ideally would not
add complexity. It might provide some nice be
On Thu, Feb 6, 2025 at 8:04 AM Zhang Mingli wrote:
> On Feb 6, 2025 at 10:49 +0800, David G. Johnston <
> david.g.johns...@gmail.com>, wrote:
>
>
> Yes, and when it does it is doing so in lieu of an error, and thus it is
> not returning the value of the setting. It does not mean the value taken
On Thu, Feb 27, 2025 at 1:42 PM Jeff Davis wrote:
> It would make more sense to me if we either (a) enforced work_mem as it
> was at the time of planning; or (b) replanned if executed with a different
> work_mem (similar to how we replan sometimes with different parameters).
>
Definitely (b).
B
Robert Haas writes:
> The thing that was bugging me a bit is that explain_format.h includes
> explain.h.
Yeah, I did not like that at all either -- it makes things a bit
circular, and I fear IWYU is going to make stupid recommendations
like not including explain.h in explain.c.
Did you look at a
On Tue, Feb 25, 2025 at 1:31 AM jian he wrote:
> hi.
> the thread "Statistics Import and Export" is quite hot.
> so a new thread for some minor issue i found.
>
>
> static int
> _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH)
> {
>
> if (strcmp(te->desc, "STATISTICS D
Hello hackers,
On Thu, Feb 27, 2025 at 9:46 AM Alexandra Wang
wrote:
> Summary of changes:
>
> v8-0001 through v8-0005:
> Refactoring and preparatory steps for the actual implementation.
>
> v8-0006 (Implement read-only dot notation for JSONB):
> I removed the vars field (introduced in v7) from
On Tue, Feb 25, 2025 at 6:08 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 25 Feb 2025 17:14:43 -0800,
> Masahiko Sawada wrote:
>
> > I've attached updated patches.
>
> Thanks.
>
> I found one more missing last ".
On Wed, Feb 26, 2025 at 9:19 PM Corey Huinker wrote:
>>>
>>> +1, let's shorten those queries. The coast is probably pretty
>>> clear now if you want to go do that.
>>
>>
>> On it.
So, I started reviewing this and my original thought about shortening
the queries testing pg_restore_relation_stats(
On Tue, Feb 18, 2025 at 1:11 PM Peter Geoghegan wrote:
> On Tue, Feb 18, 2025 at 1:04 PM Robert Haas wrote:
> > I think in cases like this there is a tendency to want to achieve an
> > even split of the original file, but in practice I think that tends
> > not to be difficult to achieve. These tw
On Thu, Feb 27, 2025 at 1:24 PM Robert Haas wrote:
> Thanks for the quick response! I have committed these patches.
I recently did something similar myself when I moved all of the nbtree
preprocessing code into its own file.
The obvious downside is that it tends to make "git blame" much less
use
As a part of this discussion:
https://www.postgresql.org/message-id/CAJVSvF6s1LgXF6KB2Cz68sHzk%2Bv%2BO_vmwEkaon%3DH8O9VcOr-tQ%40mail.gmail.com
James pointed out something interesting, which is that a prepared
statement enforces the work_mem limit at execution time, which might be
different from t
Pavel Stehule writes:
> čt 27. 2. 2025 v 13:25 odesílatel Alexander Pyhalov <
> a.pyha...@postgrespro.ru> napsal:
>>> Unfortunately, there is about 5% slowdown for inlined code, and for
>>> just plpgsql code too.
>> Hi. I've tried to reproduce slowdown and couldn't.
> I'll try to get profiles.
Pavel Stehule writes:
> čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
>> So taken together, our results are all over the map, anywhere
>> from 7% speedup to 7% slowdown. My usual rule of thumb is that
> Where do you see 7% speedup? Few lines up you wrote 0.7% faster.
Alexander got that on
Alexander Pyhalov writes:
> Now sql functions plans are actually saved. The most of it is a
> simplified version of plpgsql plan cache. Perhaps, I've missed
> something.
A couple of thoughts about v6:
* I don't think it's okay to just summarily do this:
/* It's stale;
On Mon, Feb 17, 2025 at 5:44 PM Peter Geoghegan wrote:
> I need more feedback about this. I don't understand your perspective here.
Attached is a version of the patch that will apply cleanly against
HEAD. (This is from v26 of my skip scan patch, which is why I've
skipped so many version numbers c
On Mon, Apr 22, 2024 at 2:20 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Thoughts anyone?
>
> On Thu, Feb 1, 2024 at 3:47 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> Motivated by a recent complaint [1] I found the hostssl related material
>> in our docs quite v
On Wed, Feb 26, 2025 at 4:09 PM Jeff Davis wrote:
>
> My idea was that we'd attach work_mem to each Path node and Plan node
> at create time. For example, in create_agg_path() it could do:
>
> pathnode->path.node_work_mem = work_mem;
>
> And then add to copy_generic_path_info():
>
> dest->node
Em qui., 27 de fev. de 2025 às 14:49, Andres Freund
escreveu:
> Hi,
>
> On 2025-02-27 12:44:24 -0500, Andres Freund wrote:
> > > CID 1592454: (#1 of 1): Explicit null dereferenced (FORWARD_NULL)
> > > 8. var_deref_op: Dereferencing null pointer per_buffer_data.
> >
> > That's exactly what the mes
On Thu, Feb 6, 2025 at 2:46 PM Daniel Gustafsson wrote:
> I'd be happy to help getting this in, do you have a suggested wording?
>
>
Thank you.
Attached.
David J.
From fc9768fa1de17529cddc3f3ac1fba208f7500083 Mon Sep 17 00:00:00 2001
From: "David G. Johnston"
Date: Thu, 27 Feb 2025 10:58:57 -0
Andres Freund writes:
> Ah, no, it isn't. But I still think the coverity alert and the patch don't
> make sense, as per the below:
Coverity's alert makes perfect sense if you posit that Coverity
doesn't assume that this read_stream_next_buffer call will
only be applied to a stream that has per_bu
On Thu, Feb 27, 2025 at 1:08 PM Tom Lane wrote:
>
> I wonder if it'd be a good idea to add something like
>
> Assert(stream->distance == 1);
> Assert(stream->pending_read_nblocks == 0);
> Assert(stream->per_buffer_data_size == 0);
> + A
Ahmed,
Thank you for the review.
I'm a bit confused by the reports of apply and compile errors. I didn't
touch anything involving "varlist" and see no errors then or now in my
Meson ninja build. Nor does the CI report any.
On Fri, Feb 14, 2025 at 2:01 PM Ahmed Ashour wrote:
> Feedback:
> ---
On Thu, Feb 27, 2025 at 2:21 PM Álvaro Herrera wrote:
> On 2025-Feb-27, Robert Haas wrote:
> > I see that the Redis-FDW test is failing; it will now need to include
> > "commands/explain_format.h" -- unless we something, of course.
>
> I wonder if it was really a useful idea to move the declarati
On Tue, Feb 18, 2025 at 12:49 PM Ryo Kanbayashi
wrote:
>
> On Thu, Feb 13, 2025 at 10:49 PM Fujii Masao
> wrote:
> >
> >
> >
> > On 2025/02/06 8:57, Ryo Kanbayashi wrote:
> > > On Wed, Feb 5, 2025 at 9:31 PM Ryo Kanbayashi
> > > wrote:
> > >>
> > >> Hi hackers,
> > >>
> > >> When I wrote patch
Robert Haas writes:
> On Thu, Feb 27, 2025 at 3:05 PM Tom Lane wrote:
>> Did you look at avoiding that with our standard trick of writing
>> detail-free struct declarations?
> OK, here's a patch that does that. Thoughts?
+1, but how about explain_dr.h too? It doesn't seem though that
we can av
On Thu, Feb 27, 2025 at 3:05 PM Tom Lane wrote:
> Robert Haas writes:
> > The thing that was bugging me a bit is that explain_format.h includes
> > explain.h.
>
> Yeah, I did not like that at all either -- it makes things a bit
> circular, and I fear IWYU is going to make stupid recommendations
>
On Thu, Feb 27, 2025 at 4:08 PM Tom Lane wrote:
> I was down on it to start with, on the grounds that it wasn't adding
> enough ease-of-use to justify even a relatively small amount of added
> code. I'm not sure that the dump-reload failure angle is much of a
> concern in reality, but I would hav
On 2025-Feb-27, Robert Haas wrote:
> I see that the Redis-FDW test is failing; it will now need to include
> "commands/explain_format.h" -- unless we something, of course.
I wonder if it was really a useful idea to move the declarations of
those functions from explain.h to the new explain_format
1 - 100 of 133 matches
Mail list logo
