> On Mon, Jul 14, 2025 at 05:55:13PM -0500, Jim Nasby wrote:
>
> Finally, while shared buffers is the most visible target here, there are
> other shared memory settings that have a *much* smaller surface area, and
> in my experience are going to be much more valuable from a tuning
> perspective; no
> On Tue, Jul 15, 2025 at 10:52:01PM +, Jack Ng wrote:
> >> On Mon, Jul 14, 2025 at 03:18:10PM +, Jack Ng wrote:
> >> Just brain-storming here... would moving NBuffers to shared memory solve
> >this specific issue? Though I'm pretty sure that would open up a new set of
> >synchronization is
> On Mon, Jul 14, 2025 at 03:18:10PM +, Jack Ng wrote:
> Just brain-storming here... would moving NBuffers to shared memory solve this
> specific issue? Though I'm pretty sure that would open up a new set of
> synchronization issues elsewhere, so I'm not sure if there's a net gain.
It's in f
> On Mon, Jul 14, 2025 at 11:11:36AM -0400, Andres Freund wrote:
> Hi,
>
> On July 14, 2025 10:39:33 AM EDT, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >> On Mon, Jul 14, 2025 at 10:23:23AM -0400, Andres Freund wrote:
> >> > Those steps are separat
> On Mon, Jul 14, 2025 at 10:22:17AM -0400, Burd, Greg wrote:
> I'd initialize them, expand BufferDescriptors, and adjust NBuffers. The
> clock-sweep algorithm will eventually find them and make use of them. The
> buf->freeNext should be FREENEXT_NOT_IN_LIST so that StrategyFreeBuffer() will
> do
> On Mon, Jul 14, 2025 at 10:23:23AM -0400, Andres Freund wrote:
> > Those steps are separated in time, and I'm currently trying to understand
> > what are the consequences of performing them in different order and whether
> > there are possible concurrency issues under various scenarios. Does this
> On Mon, Jul 14, 2025 at 09:42:46AM -0400, Andres Freund wrote:
> What on earth would be the point of putting a buffer on the freelist but not
> make it reachable by the clock sweep? To me that's just nonsensical.
To clarify, we're not talking about this scenario as "that's how it
would work afte
> On Mon, Jul 14, 2025 at 09:14:26AM -0400, Andres Freund wrote:
> > > Clock sweep can find any buffer, independent of whether it's on the
> > > freelist.
> >
> > It does the search based on nextVictimBuffer, where the actual buffer
> > will be a modulo of NBuffers, right? If that's correct and I
> On Mon, Jul 14, 2025 at 08:56:56AM -0400, Andres Freund wrote:
> > Ah, I see what you mean folks. But I'm talking here only about buffers
> > which will be allocated after extending shared memory -- they must go
> > through the freelist first (I don't see why not, any other options?),
> > and cl
> On Mon, Jul 14, 2025 at 10:24:50AM +0100, Thom Brown wrote:
> On Mon, 14 Jul 2025, 09:54 Dmitry Dolgov, <9erthali...@gmail.com> wrote:
>
> > > On Mon, Jul 14, 2025 at 01:55:39PM +0530, Ashutosh Bapat wrote:
> > > > You're right of course, a buffer id coul
> On Mon, Jul 14, 2025 at 01:55:39PM +0530, Ashutosh Bapat wrote:
> > You're right of course, a buffer id could be returned from the
> > ClockSweep and from the custom strategy buffer ring. Buf from what I see
> > those are picking a buffer from the set of already utilized buffers,
> > meaning that
> On Mon, Jul 14, 2025 at 10:25:51AM +0530, Ashutosh Bapat wrote:
> > Currently it's being addressed via every backend waiting for each other,
> > but I guess it could be as well managed via handling the freelist, so
> > that only "available" buffers will be inserted into the lookup table.
>
> I di
> On Sun, Jul 06, 2025 at 03:21:08PM +0200, Dmitry Dolgov wrote:
> > On Sun, Jul 06, 2025 at 03:01:34PM +0200, Dmitry Dolgov wrote:
> > * This way any backend between the ProcSignalBarriers will be able
> > proceed with whatever it's doing, and there is need to make sur
on a 64-bit ARM machine. `make check` also passes.
I'm attaching the patch.
Regards,
DmitryFrom: Dmitry Mityugov
Date: Thu, 10 Jul 2025 22:05:12 +0300
Subject: Use pg_assume in jsonb_util.c to fix GCC 15 warnings
Recently introduced pg_assume macro is a great tool to silence GCC 15 war
x27;m sorry in advance for any mistakes.
This modification was passed through pgindent, clearly compiles with GCC
15.1.1 on Arch Linux x86 64-bit, and ‘make check’ successfully passes
for it. I'm attaching the patch.
Best regards,
DmitryFrom: Dmitry Mityugov
Date: Mon, 7 Jul 2025 17:5
> On Mon, Jul 07, 2025 at 07:12:50PM +0530, Ashutosh Bapat wrote:
>
> My current proposal is ALTER SYSTEM ... SET + pg_reload_conf() with
> pending mark + pg_apply_pending_conf(, parameters>). The third function would take a GUC name as parameter
> and complete the pending application change. If t
> On Mon, Jul 07, 2025 at 01:57:42PM +0200, Tomas Vondra wrote:
> > It could be potentialy useful for any GUC that controls a resource
> > shared between backend, and requires restart. To make this GUC
> > changeable online, every backend has to perform some action, and they
> > have to coordinate
> On Sun, Jul 06, 2025 at 03:01:34PM +0200, Dmitry Dolgov wrote:
> * This way any backend between the ProcSignalBarriers will be able
> proceed with whatever it's doing, and there is need to make sure it
> will not access buffers that will soon disappear. A suggestion so far
&
> On Fri, Jul 04, 2025 at 04:41:51PM +0200, Dmitry Dolgov wrote:
> > v5-0003-Introduce-pss_barrierReceivedGeneration.patch
> >
> > 1) Do we actually need this? Isn't it enough to just have two barriers?
> >Or a barrier + condition variable, or something l
> On Fri, Jul 04, 2025 at 05:23:29PM +0200, Tomas Vondra wrote:
> >> 2) pending GUC changes
> >>
> >> Perhaps this should be a separate utility command, or maybe even just
> >> a new ALTER SYSTEM variant? Or even just a function, similar to what
> >> the "online checksums" patch did, possibly combi
> On Fri, Jul 04, 2025 at 02:06:16AM +0200, Tomas Vondra wrote:
> I took a look at this patch, because it's somewhat related to the NUMA
> patch series I posted a couple days ago, and I've been wondering if
> it makes some of the NUMA stuff harder or simpler.
Thanks a lot for the review! It's a pl
it touches the shared memory.
>
> I have added Dmitry to this thread since he has written most of the
> shared memory handling code.
Thanks! I like the idea behind this patch series. I haven't read it in
details yet, but I can imagine both patches (interleaving and online
resizing)
failed
WARNING: Timed out: nextMXact 24497746 tmpMXact 24497744
Best regards,
Dmitry.
On 25.06.2025 16:44, Dmitry wrote:
I will definitely try to reproduce the problem with your patch.
Hi Andrey!
I checked with the patch, unfortunately the problem is also reproducible.
Client processes wake up after a second and try to get information about the
members of the multixact again
On 25.06.2025 12:34, Andrey Borodin wrote:
On 25 Jun 2025, at 11:11, Dmitry wrote:
#6 GetMultiXactIdMembers (multi=45559845, members=0x7ffdaedc84b0,
from_pgupgrade=, isLockOnly=)
at
/usr/src/postgresql-17-17.5-1.pgdg24.04+1/build/../src/backend/access/transam/multixact.c
#24 0x57c4402bcd2d in main (argc=17, argv=0x57c4747fb140) at
/usr/src/postgresql-17-17.5-1.pgdg24.04+1/build/../src/backend/main/main.c:199
Could you please help me to fix the problem of stuck 'client backend'
processes?
I kindly ask you for any ideas and recommendations!
Best regards,
Dmitry
> On Fri, Jun 20, 2025 at 12:19:31PM +0200, Dmitry Dolgov wrote:
> Thanks! I've reworked the series to implement approach suggested by
> Thomas, and applied your patches to support buffers shrinking on top. I
> had to restructure the patch set, here is how it looks like right now:
ion as partition of permanent
relation "t"
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
Hi, jian he!
Thank you very much for your emails!
Unfortunately, due to urgent tasks at my work, I do not have time to
look through your notes today and tomorrow.
But I will definitely do it at the beginning of next week.
--
With best regards,
Dmitry Koval
Postgres Professional: http
Some notes to the patch. ...
Thanks for the notes!
I'll try to make edits in the next few days.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
On Mon, May 26, 2025, 8:01 AM Thomas Munro wrote:
> But ... I'm not even sure if we can say that our
> I/O arrivals have a Poisson distribution, since they are not all
> independent.
>
Yeah, a good point, one have to be careful with assumptions about
distribution -- from what I've read many proc
> On Sun, Apr 13, 2025 at 04:59:54AM GMT, Thomas Munro wrote:
> It's hard to know how to set io_workers=3. If it's too small,
> io_method=worker's small submission queue overflows and it silently
> falls back to synchronous IO. If it's too high, it generates a lot of
> pointless wakeups and sched
> On Sun, May 25, 2025 at 02:15:12AM GMT, Thomas Munro wrote:
> On Sun, May 25, 2025 at 1:56 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > I've been rebasing the patch for online resizing of shared memory, and
> > noticed something strange about IoWorkerMain: alt
Hi,
I've been rebasing the patch for online resizing of shared memory, and
noticed something strange about IoWorkerMain: although it sets the
handler SignalHandlerForConfigReload, it doesn't look like it acts upon
ConfigReloadPending. From what I see it happens because it only does
CHECK_FOR_INTER
ctually. This is the behavior on HEAD, and I don't
> > > get why
> > > the first list with the casts does not get squashed, while the second one
> > > does.
> > > I will check IsSquashableConst tomorrow unless Dmitry gets to it first.
> >
> >
gt; > $3 in ($4, cast($5 as int), $6, (cast($7 as int)), $8, $9, (cast($10 as
> > text))::int)
>
> This is interesting actually. This is the behavior on HEAD, and I don't get
> why
> the first list with the casts does not get squashed, while the second one
> does.
&
> On Wed, May 21, 2025 at 08:22:19PM GMT, Sami Imseih wrote:
> > > > At the same time AFAICT there isn't much more code paths
> > > > to worry about in case of a LocationExpr as a node
> > >
> > > I can imagine there are others like value expressions,
> > > row expressions, json array expressions,
superuser can bypass all permission checks.
superuser can attach any table to the partitioned table as he wants.
That's right.
Using SUPERUSER may be a rare situation, but it needs to be processed.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
for example:
...
If in both examples you replace
create role bob;
with
create role bob SUPERUSER;
and in the second example add "set role bob;" before "alter table ..."
query, then no error will be occur.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
> On Tue, May 20, 2025 at 04:50:12PM GMT, Sami Imseih wrote:
> > At the same time AFAICT there isn't much more code paths
> > to worry about in case of a LocationExpr as a node
>
> I can imagine there are others like value expressions,
> row expressions, json array expressions, etc. that we may
> w
wner of the split partition.)
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
> On Tue, May 20, 2025 at 06:30:25AM GMT, Michael Paquier wrote:
> On Mon, May 12, 2025 at 06:40:43PM -0400, Sami Imseih wrote:
> > Also, LocationExpr is not really an expression node, but a wrapper to
> > an expression node, so I think it's wrong to define it as a Node and be
> > required to add t
> On Tue, May 20, 2025 at 11:03:52AM GMT, Dmitry Dolgov wrote:
> > By the way, the new test cases for ARRAY lists are sent in the last
> > patch of the series posted on this thread:
> > https://www.postgresql.org/message-id/7zbzwk4btnxoo4o3xbtzefoqvht54cszjj4bol22fm
> On Mon, May 12, 2025 at 06:40:43PM GMT, Sami Imseih wrote:
> > The static variables was only part of the concern, another part was
> > using A_Expr to carry this information, which will have impact on lots
> > of unrelated code.
>
> What would be the problem if A_Expr carries an extra pointer to
merged have different owners?
a) current user (since he is the one who creates new table);
b) merging of partitions should be forbidden if they have different owners.
Please, advise what seems to be the best solution for points 1 and 2.
With best regards,
Dmitry Koval
Postgres Professional: http
> On Fri, May 09, 2025 at 12:47:19PM GMT, Sami Imseih wrote:
> So, I think we can create a new parse node ( parsenode.h ) that will only be
> used in parsing (and gram.c only ) to track the start/end locations
> and List and
> based on this node we can create A_ArrayExpr and A_Expr with the List
>
> On Fri, May 09, 2025 at 10:12:24AM GMT, Dmitry Dolgov wrote:
> Agree, I'll try to extend number of test cases here as a separate patch.
Here is the extended version, where start/end is replaced by
location/length, array_expr is handled as well, and more ARRAY cases are
a
> On Fri, May 09, 2025 at 08:47:58AM GMT, Michael Paquier wrote:
> SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
> - query| calls
> -+---
> - SELECT ARRAY[$1 /*, ... */]
> On Fri, May 09, 2025 at 02:35:33PM GMT, Michael Paquier wrote:
> On Fri, May 09, 2025 at 11:05:43AM +0800, Junwang Zhao wrote:
> > Why not a location and a length, it should be more natural, it
> > seems we use this convention in some existing nodes, like
> > RawStmt, InsertStmt etc.
>
> These ar
> On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote:
> On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote:
> > Ah, I see what you mean. I think the idea is fine, it will simplify
> > certain things as well as address the issue. But I'm afraid adding
&g
> On Tue, May 06, 2025 at 03:01:32PM GMT, Sami Imseih wrote:
> > > Without properly accounting for the boundaries of the list of
> > > expressions, i.e.,
> > > the start and end positions of '(' and ')' or '[' and ']' and normalizing
> > > the
> > > expressions in between, it will be very difficu
> On Tue, May 06, 2025 at 01:32:48PM GMT, Sami Imseih wrote:
> > I also agree with Alvaro that this discussion doesn't justify a
> > revert. If the pre-v18 behavior wasn't chiseled on stone tablets,
> > the new behavior isn't either. We can improve it some more later.
>
> As I was looking further
> On Tue, May 06, 2025 at 11:50:07PM GMT, Junwang Zhao wrote:
> Would it make sense to rename `RecordConstLocation` to something like
> `RecordExpressionLocation` instead?
Yeah, naming is hard. RecordExpressionLocation is somehow more vague,
but I see what you mean, maybe something along these lin
> On Tue, May 06, 2025 at 04:23:07AM GMT, Jack Ng wrote:
> Thanks Dmitry. Right, the coordination mechanism in v4-0006 works as expected
> in various tests (sorry, I misunderstood some details initially).
Great, thanks for checking.
> I also want to report a couple of minor issues
> On Thu, May 01, 2025 at 09:55:47PM GMT, Dmitry Dolgov wrote:
> > On Thu, May 01, 2025 at 09:29:13AM GMT, Michael Paquier wrote:
> >
> > I agree that the current solution we have in the tree feels incomplete
> > because we are not taking into account the most common
> On Fri, May 02, 2025 at 04:18:37PM GMT, Michael Paquier wrote:
> On Fri, May 02, 2025 at 09:13:39AM +0200, Dmitry Dolgov wrote:
> > Squashing constants was ment to be a first step towards doing the same
> > for other types of queries (params, rte_values), reverting it to
> &
> On Fri, May 02, 2025 at 07:10:19AM GMT, Michael Paquier wrote:
> > I am really leaning towards that we should revert this feature as the
> > limitation we have now with parameters is a rather large one and I think
> > we need to go back and address this issue.
>
> I am wondering if this would not
> On Thu, May 01, 2025 at 09:29:13AM GMT, Michael Paquier wrote:
>
> I agree that the current solution we have in the tree feels incomplete
> because we are not taking into account the most common cases that
> users would care about. Now, allowing PARAM_EXTERN means that we
> allow any expression
> On Thu, Apr 17, 2025 at 07:05:36PM GMT, Ni Ku wrote:
> I also have a related question about how ftruncate() is used in the patch.
> In my testing I also see that when using ftruncate to shrink a shared
> segment, the memory is freed immediately after the call, even if other
> processes still have
> On Fri, Apr 18, 2025 at 10:06:23AM GMT, Konstantin Knizhnik wrote:
> The only drawback is that we are loosing content of shared buffers in case
> of resize. It may be sadly, but not looks like there is no better
> alternative.
No, why would we loose the content? If we do mremap, it will leave th
> On Fri, Apr 18, 2025 at 09:17:21PM GMT, Thomas Munro wrote:
> I was imagining that you might map some maximum possible size at the
> beginning to reserve the address space permanently, and then adjust
> the virtual memory object's size with ftruncate as required to provide
> backing. Doesn't tha
> On Thu, Apr 17, 2025 at 02:21:07PM GMT, Konstantin Knizhnik wrote:
>
> 1. Performance of Postgres CLOCK page eviction algorithm depends on number
> of shared buffers. My first native attempt just to mark unused buffers as
> invalid cause significant degrade of performance
Thanks for sharing!
Ri
> On Thu, Apr 17, 2025 at 03:22:28PM GMT, Ashutosh Bapat wrote:
>
> In an offlist chat Thomas Munro mentioned that just ftruncate() would
> be enough to resize the shared memory without touching address maps
> using mmap and munmap().
>
> ftruncate man page seems to concur with him
>
>If th
> On Mon, Apr 14, 2025 at 10:40:28AM GMT, Ashutosh Bapat wrote:
>
> However, when we put back the patches to shrink buffers, we will evict
> the extra buffers, and shrink - if all the processes haven't
> participated in the barrier by then, some of them may try to access
> those buffers - re-instal
> On Fri, Mar 28, 2025 at 09:23:13AM GMT, Filip Janus wrote:
> > +else
> > +if (nbytesOriginal - file->pos != 0)
> > +/* curOffset must be corrected also if compression is
> > + * enabled, nbytes was changed by compression but we
> > + * have to use t
> On Fri, Apr 11, 2025 at 08:04:39PM GMT, Ashutosh Bapat wrote:
> On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > Yes, you're right, plain dynamic Barrier does not ensure all available
> > processes will be synchronized.
> On Wed, Apr 09, 2025 at 01:20:16PM GMT, Ashutosh Bapat wrote:
> ../../coderoot/pg/src/include/storage/s_lock.h:93:2: error: #error
> "s_lock.h may not be included from frontend code"
>
> How about this? Why is that happening?
The same -- as you can see it comes from compiling pg_numa.c, which as
> On Wed, Apr 09, 2025 at 11:12:18AM GMT, Ashutosh Bapat wrote:
> On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > In the new v4 version
> > of the patch the first option is implemented.
> >
>
> The patches don't a
> On Thu, Mar 20, 2025 at 04:55:47PM GMT, Ni Ku wrote:
>
> I ran some simple tests (outside of PG) on linux kernel v6.1, which has
> this commit that added some hugepage support to mremap (
> https://patchwork.kernel.org/project/linux-mm/patch/20211013195825.3058275-1-almasrym...@google.com/
> ).
>
> On Sun, Mar 23, 2025 at 06:21:33PM GMT, Tom Lane wrote:
>
> FWIW, I think the 0004 patch is about to be mostly obsoleted by
> Andrei's proposal at [1]. To the extent that it's not obsoleted,
> I question whether it's something we want at all, given the ground
> rule that unprivileged users are n
On Tue, Mar 25, 2025, 7:40 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
>>> On Tue, Mar 25, 2025, 6:28 PM Álvaro Herrera
> wrote:
>
> On 2025-Mar-25, Tom Lane wrote:
>
> > If this GUC sticks around, it should be at least PGC_SUSET (on
>
> > the a
>
>
>> On Tue, Mar 25, 2025, 6:28 PM Álvaro Herrera
wrote:
On 2025-Mar-25, Tom Lane wrote:
> If this GUC sticks around, it should be at least PGC_SUSET (on
> the analogy of compute_query_id) to make it harder to break
> pg_stat_statements that way.
I have no problem making it superuser-only,
> On Fri, Mar 21, 2025 at 04:48:30PM GMT, Ni Ku wrote:
> Thanks for your insights and confirmation, Dmitry.
> Right, I think the anonymous fd approach would work to keep the memory
> contents intact in between munmap and mmap with the new size, so bufferpool
> expansion would work.
> On Tue, Mar 18, 2025 at 02:54:18PM GMT, Sami Imseih wrote:
> I want to mention that the current patch does not deal
> with external parameters ( prepared statements ) [0] [1]. This could be a
> follow-up, as it may need some further discussion. It is important to
> address this case, IMO.
Sure,
> On Tue, Mar 18, 2025 at 07:33:25PM GMT, Álvaro Herrera wrote:
>
> By the way, I'm still open to adding the 'powers' mechanism that was
> discussed earlier and other simple additions on top of what's there now,
> if you have some spare energy to spend on this. (For full disclosure:
> the "powers"
> On Mon, Mar 17, 2025 at 08:14:16PM GMT, Álvaro Herrera wrote:
> On 2025-Mar-17, Álvaro Herrera wrote:
>
> > You can see my patch on top of yours here:
> > https://github.com/alvherre/postgres/commits/query_id_squash_values/
> > and the CI run here:
> > https://cirrus-ci.com/build/5660053472018432
> On Mon, Mar 17, 2025 at 12:07:44PM GMT, vignesh C wrote:
>
> I noticed that the feedback from Sami at [1] has not yet been
> addressed, I have changed the status to Waiting on Author, kindly
> address them and update the status to Needs review.
> [1] -
> https://www.postgresql.org/message-id/CAA
> On Mon, Mar 03, 2025 at 12:56:24PM GMT, Álvaro Herrera wrote:
> In the meantime, here's v28 which is Dmitry's v27 plus pgindent. No
> other changes. Dmitry, were you planning to submit a new version?
Nope, there was nothing I wanted to add so far.
> 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.
> 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 new version of the patch, which contains a proposal about how to
c
> On Mon, Nov 25, 2024 at 11:20:05AM GMT, Ashutosh Bapat wrote:
> > I've tried to reproduce some subset of those results, in case if I would
> > be able to notice anything useful. Strangely enough, I wasn't able to
> > get much boost in planning time e.g. with 4 first patches, 100
> > partitions an
ng.
---
I suggest replace Assert with an error message, see
[v1-0001-draft-of-fix.patch]. This is not a final fix as I am confused
by the comment for Assert: "we don't support an UPDATE of INSERT ON
CONFLICT for a partitioned table".
(Why "don't support an UPDATE"?
> On Mon, Feb 17, 2025 at 01:50:00PM GMT, Sami Imseih wrote:
> > This test was to catch a crash that was happening in older version of
> > the patch, so it doesn't have to verify the actual pgss entry.
>
> It seems odd to keep this test because of crash behavior experienced
> in a previous version
> On Mon, Feb 17, 2025 at 09:51:32AM GMT, Sami Imseih wrote:
> > This should do it. The last patch for today,
>
> I looked at v27 today and have a few comments.
>
> 1/ It looks like the CTE test is missing a check for results.
This test was to catch a crash that was happening in older version of
t
> On Fri, Feb 14, 2025 at 09:06:24AM GMT, Sami Imseih wrote:
> I think it will be sad to not include this very common case from
> the start, because it is going to be one of the most common
> cases.
>
> Wouldn't doing something like this inside IsMergeableConst
> """
> if (!IsA(arg, Const) && !IsA(
> On Fri, Feb 14, 2025 at 11:12:25PM GMT, Julien Rouhaud wrote:
> > > There seems to be an off-by-1 error in parameter numbering when merging
> > > them.
> >
> > There are indeed three constants, but the second is not visible in the
> > query text. Maybe makes sense to adjust the number in this ca
> On Fri, Feb 14, 2025 at 10:39:45PM GMT, Julien Rouhaud wrote:
> There seems to be an off-by-1 error in parameter numbering when merging them.
There are indeed three constants, but the second is not visible in the
query text. Maybe makes sense to adjust the number in this case, let me
try.
> Not
> On Fri, Feb 14, 2025 at 05:26:19AM GMT, Sami Imseih wrote:
> > > On Thu, Feb 13, 2025 at 05:08:45PM GMT, Sami Imseih wrote:
> > > Constants passed as parameters to a prepared statement will not be
> > > handled as expected. I did not not test explicit PREPARE/EXECUTE
> > > statement,
> > > but I
> On Fri, Feb 14, 2025 at 05:57:01PM GMT, Julien Rouhaud wrote:
> On Fri, Feb 14, 2025 at 10:36:48AM +0100, Álvaro Herrera wrote:
> > On 2025-Feb-14, Julien Rouhaud wrote:
> >
> > > Since the merging is a yes/no option (I think there used to be some
> > > discussions
> > > about having a threshold
> On Thu, Feb 13, 2025 at 05:08:45PM GMT, Sami Imseih wrote:
> Constants passed as parameters to a prepared statement will not be
> handled as expected. I did not not test explicit PREPARE/EXECUTE statement,
> but I assume it will have the same issue.
This is the same question of supporting variou
Hi!
Function EvalPlanQualFetchRowMark contains an assignment
ExecRowMark *erm = earm->rowmark;
before assert
Assert(earm != NULL);
Maybe these lines need to be swapped?
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
diff --git a/src/back
> On Thu, Feb 13, 2025 at 01:47:01PM GMT, Álvaro Herrera wrote:
> Also, how wed are you to
> "query_id_merge_values" as a name? It's not in any way obvious that
> this is about values in arrays. How about query_id_squash_arrays? Or
> are you thinking in having values in other types of structures
> On Wed, Feb 12, 2025 at 08:48:03PM GMT, Dmitry Dolgov wrote:
> > On Wed, Feb 12, 2025 at 07:39:39PM GMT, Álvaro Herrera wrote:
> > The nastiness level of this seems quite low, compared to what happens to
> > this other example if we didn't handle these easy cases:
>
> On Wed, Feb 12, 2025 at 07:39:39PM GMT, Álvaro Herrera wrote:
> The nastiness level of this seems quite low, compared to what happens to
> this other example if we didn't handle these easy cases:
>
> create table t (a float);
> select i from t where i in (1, 2);
> select i from t where i in (1, '
> On Tue, Feb 11, 2025 at 08:00:27PM GMT, Dmitry Dolgov wrote:
> > Hmm, what about doing something much simpler, such as testing whether
> > there's just a CoerceViaIO/RelabelType around a Const or a one-parameter
> > function call of an immutable boostrap-OID fu
> On Tue, Feb 11, 2025 at 07:51:43PM GMT, Álvaro Herrera wrote:
> On 2025-Feb-11, Dmitry Dolgov wrote:
>
> > > On Tue, Feb 11, 2025 at 10:49:59AM GMT, Sami Imseih wrote:
> > > I have only looked at 0001, but I am wondering why
> > > query_id_const_merge is a
;2', '3', '4');
> and so on. There are no casts here because these literals are of type
> unknown.
>
> I suppose this is telling us that detecting the case with consts wrapped
> in casts is not really optional. (Dmitry said this was supported at
> early stag
waits for COPY to finish, and only
then moves that temp files to data area, because of the large transaction
or something. Would be cool to understand the reason.
On Mon, Feb 3, 2025 at 22:31 Amit Kapila wrote:
> On Mon, Feb 3, 2025 at 5:51 PM Dmitry Koterov
> wrote:
> >
> > H
y on the
destination they are different, right after the copying. (There are not a
lot of writes to this table happening on the source happening while copying
BTW.)
Maybe that could hint on why temp files are used?
On Mon, Feb 3, 2025 at 4:21 AM Dmitry Koterov
wrote:
> Here is the list of tmp
/main/base/4
2.3M17/main/base/5
12G 17/main/base/pgsql_tmp
6.3G17/main/pg_wal
So the question, why does it use temp files. Why not just writes directly
to WAL+data.
On Mon, Feb 3, 2025 at 3:04 AM Dmitry Koterov
wrote:
> Hi.
>
> 1. Those are temp files on the destination n
1 - 100 of 861 matches
Mail list logo
