Over in [1], there was some uncertainty about whether locking an
unrelated partition was expected behaviour or not for the particular
use-case which used a generic plan to scan a partitioned table and all
of the partitions.
I noticed that we don't mention this in the docs and though that
perhaps w
On Fri, 21 Mar 2025 at 18:45, Michael Paquier wrote:
> Potential ideas about optimizing the branches seem worth
> investigating, I am not sure that I would be able to dig into that
> until the feature freeze gong, unfortunately, and it would be nice to
> fix this issue for this release. I'll see
Hi,
On 2025-03-23 08:55:29 -0700, Noah Misch wrote:
> On Sun, Mar 23, 2025 at 11:11:53AM -0400, Andres Freund wrote:
> Unrelated to the above, another question about io_uring:
>
> commit da722699 wrote:
> > +/*
> > + * Need to submit staged but not yet submitted IOs using the fd, otherwise
> > +
On Tue, Mar 25, 2025 at 11:05 AM Zhijie Hou (Fujitsu)
wrote:
>
> Hi,
>
> When testing the slot synchronization with logical replication slots that
> enabled two_phase decoding, I found that transactions prepared before
> two-phase
> decoding is enabled may fail to replicate to the subscriber afte
On 24/3/2025 23:05, David Rowley wrote:
On Tue, 25 Mar 2025 at 10:23, Andrei Lepikhov wrote:
On 3/23/25 22:16, David Rowley wrote:
Once again, I'm not necessarily objecting to hit and evict ratios
being shown, I just want to know they're actually useful enough to
show and don't just bloat the
On Mon, 24 Mar 2025 at 13:21, jian he wrote:
>
> I am not sure this is what we want.
> Anyway, I attached both two version
Few comments
1) I understood the problem, your first approach is ok for me.
2) Here in error we say column c1 violates not-null constraint and in
the context we show column
Hi,
> On Tue, Mar 11, 2025 at 5:39 AM Andy Fan wrote:
>> Currently when a query needs some parallel workers, postmaster spawns
>> some backend for this query and when the work is done, the backend
>> exit. there are some wastage here, e.g. syscache, relcache, smgr cache,
>> vfd cache and fork/
Rebased all patches on the current master, renumbered
them to be linear and marked as v3 version.
With the best regards,
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres CompanyFrom 84ae0a626d5820f93a3423a518becb6dafc0a2af Mon Sep 17 00:00:00 2001
Fr
Dear hackers,
This is a follow-up thread of [1]. I think it could be considered for
PG19 but let me share now.
Background
==
Currently, all relsync cache entries would be discarded when the pg_namespace is
modified. This mechanism works well but is sometimes not efficient.
Theoretically,
On Mon, Mar 24, 2025 at 7:23 PM Amit Langote wrote:
>
> Ok, thanks for that analysis. I don't think there's anything about
> the patch that makes it particularly less suitable for pwj=on.
>
I agree.
> I read patch 0002 in detail last week and wrote a follow-up patch
> (0003), mostly for cosmeti
On Sat, 2025-03-22 at 09:39 -0700, Jeff Davis wrote:
> For some reason I'm getting a decline of about 3% in the c.sql test
> that seems to be associated with the accessor functions, even when
> inlined. I'm also not seeing as much benefit from the inlining of the
> MemoryContextMemAllocated(). But
On Mon, Mar 24, 2025 at 8:51 PM Michael Paquier wrote:
> On Mon, Mar 24, 2025 at 09:38:35PM -0500, Sami Imseih wrote:
> > > select * from foo s1;
> > > select * from foo s2;
> >
> > ah, thanks for pointing this out. Not as good of a workaround as
> > a comment since one must change aliases, but a
On Tue, Mar 25, 2025 at 01:17:22AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
> >> 2. Tools that are not entitled to set the value of the GUC are forced
> >> to be prepared to cope with any setting. That can be anywhere from
> >>
On Sat, 2025-03-08 at 14:09 -0500, Corey Huinker wrote:
> >
> > except it is perfectly clear that you *asked for* data and
> > statistics, so you get what you asked for. however the user
> > conjures in their heads what they are looking for, the logic is
> > simple, you get what you asked for.
>
Hi,
When testing the slot synchronization with logical replication slots that
enabled two_phase decoding, I found that transactions prepared before two-phase
decoding is enabled may fail to replicate to the subscriber after being
committed on a promoted standby following a failover.
To reproduce
Julien Rouhaud writes:
> On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
>> 2. Tools that are not entitled to set the value of the GUC are forced
>> to be prepared to cope with any setting. That can be anywhere from
>> painful to impossible.
> Didn't that ship already sailed in pg14 wh
Hi,
On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
>
> I'm not opining one way or the other on whether squashing an IN list
> is desirable. My point is that a GUC is a poor way to make --- or
> really, avoid making --- such decisions. The reasons we took away
> from previous experimen
On Mon, Mar 24, 2025 at 6:08 PM Ashutosh Bapat
wrote:
>
> On Fri, Mar 21, 2025 at 6:59 PM Shubham Khanna
> wrote:
> >
> > On Thu, Mar 20, 2025 at 4:53 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Thu, Mar 20, 2025 at 10:25 AM Shubham Khanna
> > > wrote:
> > >
> > > >
> > > > The attached patches
On Mon, Mar 24, 2025 at 5:41 PM Shlok Kyal wrote:
>
> On Mon, 24 Mar 2025 at 15:56, Shubham Khanna
> wrote:
> >
> > On Mon, Mar 24, 2025 at 12:29 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Dear Shubham,
> > >
> > > > I have reviewed and merged the proposed changes into the patch. The
> >
Andrei Lepikhov writes:
> On 3/22/25 23:49, Tom Lane wrote:
>> * It is not clear to me what permission restrictions we should put
>> on pg_get_loaded_modules, ...
> I vote for the idea of stripping the full path to just a filename.
Works for me. v7 attached does it that way.
>> * I'm not happy
Hi Dean,
Thanks for the patch!
I reviewed the patch and it looks good to me. I’ve run some tests, and
everything works as expected.
I have one minor thought:
On Sun, Mar 2, 2025 at 2:30 AM Dean Rasheed
wrote:
> On Thu, 14 Nov 2024 at 22:35, Dean Rasheed
> wrote:
> >
> > On Thu, 14 Nov 2024 a
> Exactly. Like Tom I'm not really worried about the proposal, but of
> course I could prove to be wrong. I am ready to assume that bloat in
> pgss entries caused by temp tables is a more common case.
I ran installcheck-parallel with the patch and without the patch
3x, and the reduction in pg_s_
On Tue, Mar 25, 2025 at 8:31 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> While reading the code, I found $SUBJECT. It says:
>
> ```
> /*
> * Publication relation/schema map syscache invalidation callback
> *
> * Called for invalidations on pg_publication and pg_namespace.
> */
> st
Sami Imseih writes:
>> I don't like that GUC and I would not like this one either. We
>> learned years ago that GUCs that change query semantics are a bad
>> idea, but apparently now we have hackers who need to relearn that
>> lesson the hard way.
> query_id_squash_values has a much weaker argum
On 2025-03-22 20:23, Jelte Fennema-Nio wrote:
On Wed, 19 Mar 2025 at 14:15, torikoshia
wrote:
BTW based on your discussion, I thought this patch could not be merged
anytime soon. Does that align with your understanding?
Yeah, that aligns with my understanding. I don't think it's realistic
to
On Mon, Mar 24, 2025 at 11:45 AM Nathan Bossart
wrote:
> On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> > В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь
> Nathan
> > Bossart написал:
> >
> >> For the sake of discussion, here is what the enum approach would
On Mon, Mar 24, 2025 at 10:30:59PM -0500, Sami Imseih wrote:
>> Sami Imseih writes:
>>> I agree that some may want stats to merge for the same tables,
>>> and others may not. I will suggest this with some hesitation, but why not
>>> make this behavior configurable via a GUC?
>>> We recently introd
On Mon, Mar 24, 2025 at 09:38:35PM -0500, Sami Imseih wrote:
> > select * from foo s1;
> > select * from foo s2;
>
> ah, thanks for pointing this out. Not as good of a workaround as
> a comment since one must change aliases, but at least there is
> a workaround...
Exactly. Like Tom I'm not reall
On Mon, Mar 24, 2025 at 04:41:35PM +0100, Christoph Berg wrote:
> Re: Michael Paquier
>> +++ b/src/backend/nodes/queryjumblefuncs.c
>> @@ -33,6 +33,7 @@
>> #include "postgres.h"
>>
>> #include "access/transam.h"
>> +#include "catalog/namespace.h"
>
> No longer needed.
Indeed.
>> +++ b/contri
Hi Kuroda-san,
On Mon, Mar 24, 2025 at 04:54:21AM +, Hayato Kuroda (Fujitsu) wrote:
> > So, I'm not sure I like the idea that much, but thinking out loud: I wonder
> > if
> > we could bypass the "active" slot checks in 16 and 17 and use injection
> > points as
> > proposed as of 18 (as we ne
On Tue, Mar 25, 2025 at 8:51 AM vignesh C wrote:
>
> On Fri, 21 Mar 2025 at 16:44, Nisha Moond wrote:
> >
> > On Fri, Mar 21, 2025 at 3:38 PM Amit Kapila wrote:
> > >
> > > On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Fri, Mar 21, 2025 at 12:50 PM Nisha M
> Sami Imseih writes:
> > I agree that some may want stats to merge for the same tables,
> > and others may not. I will suggest this with some hesitation, but why not
> > make this behavior configurable via a GUC?
> > We recently introduced query_id_squash_values for controlling
> > the merge of a
Sami Imseih writes:
> I agree that some may want stats to merge for the same tables,
> and others may not. I will suggest this with some hesitation, but why not
> make this behavior configurable via a GUC?
> We recently introduced query_id_squash_values for controlling
> the merge of an IN list, m
On Tue, 25 Mar 2025 at 11:15, Tom Lane wrote:
> FWIW, I share these doubts about whether these values are useful
> enough to include in the default EXPLAIN output. My main beef
> with them though is that they are basically numbers derived along
> the way to producing a cost estimate, and I don't
Dear hackers,
> I've pushed the patches. Thanks!
This is a closing post. Fujii-san has pushed patches and no BF failures till
now.
This patch does not modify the synopsis part, but it is intentional.
Per [1], we would discuss the manner for documentations in another thread.
I've closed the CF e
> On Mon, Mar 24, 2025 at 02:36:05PM -0500, Sami Imseih wrote:
> >> Ideally we can also land the jumble funcs work in the other thread
> >> to allow extensions to re-use the
> >> in-core logic for jumbling expressions found in plan node trees.
> >
> > IIUC, there should be a refactor I am working o
On Fri, 21 Mar 2025 at 16:44, Nisha Moond wrote:
>
> On Fri, Mar 21, 2025 at 3:38 PM Amit Kapila wrote:
> >
> > On Fri, Mar 21, 2025 at 1:48 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Fri, Mar 21, 2025 at 12:50 PM Nisha Moond wrote:
> > >
> > > > Thanks, Hou-san, for the review and fix pa
Dear Vignesh,
> Currently, error reports for database, publication, subscription, and
> replication slots do not include the option name. This has been
> addressed by including the option name in the error messages, ensuring
> consistency similar to remove option.
Confirmed all error reporting in
Dear hackers,
While reading the code, I found $SUBJECT. It says:
```
/*
* Publication relation/schema map syscache invalidation callback
*
* Called for invalidations on pg_publication and pg_namespace.
*/
static void
rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
```
Hi,
On 2025-03-24 19:20:37 -0700, Noah Misch wrote:
> On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote:
> > static void
> > TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits,
> > - bool forget_owner)
> > +
> select * from foo s1;
> select * from foo s2;
ah, thanks for pointing this out. Not as good of a workaround as
a comment since one must change aliases, but at least there is
a workaround...
> As against this, there is probably also a set of people who would
> *like* identical queries on identic
Hi,
On 2025-03-24 17:45:37 -0700, Noah Misch wrote:
> (We may be due for a test mode that does smgrreleaseall() at every
> CHECK_FOR_INTERRUPTS()?)
I suspect we are. I'm a bit afraid of even trying...
...
It's extremely slow - but at least the main regression as well as the aio tests
pass!
>
On Sat, 1 Mar 2025 at 04:35, Jeff Davis wrote:
>
> On Mon, 2024-12-16 at 20:05 -0800, Jeff Davis wrote:
> > On Wed, 2024-10-30 at 08:08 -0700, Jeff Davis wrote:
> >
>
> Rebased v14.
>
> The approach has changed multiple times. It starte off with more in-
> core code, but in response to review feed
Sami Imseih writes:
> For example, I have seen users add comments to SQLs to differentiate
> similar SQLs coming from different tenants. This patch makes this no longer a
> somewhat decent workaround to overcome the fact that pg_stat_statements
> does not track schemas or search path.
Well, the
On Tue, Mar 11, 2025 at 5:39 AM Andy Fan wrote:
> Currently when a query needs some parallel workers, postmaster spawns
> some backend for this query and when the work is done, the backend
> exit. there are some wastage here, e.g. syscache, relcache, smgr cache,
> vfd cache and fork/exit syscall
On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote:
> Subject: [PATCH v2.11 09/27] bufmgr: Implement AIO read support
[I checked that v2.12 doesn't invalidate these review comments, but I didn't
technically rebase the review onto v2.12's line numbers.]
> static void
> TerminateBuffer
On Sat, Mar 8, 2025 at 7:21 AM Andres Freund wrote:
>
> FWIW, I am fairly certain that any non-toy algorithm that requires a full
> memory barrier instead of just an acquire in case of a CAS failure is chock
> full of concurrency bugs.
Yeah -- off the top of my head, I can think of only two CAS p
Hi,
On 2025-03-23 09:32:48 -0700, Noah Misch wrote:
> Another candidate description string:
>
> AIO_COMPLETED_SHARED "Waiting for another process to complete IO."
I liked that one and adopted it.
> > A more minimal change would be to narrow AIO_IO_URING_COMPLETION to
> > "execution" or someth
> So your idea to use the relation name in eref while skipping the
> column list looks kind of promising. Per se the attached. Thoughts?
I feel really uneasy about this behavior becoming the default.
I can bet there are some users which run common queries across
different schemas ( e.g. multi-te
On Wed, Mar 19, 2025 at 6:25 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 19 Mar 2025 17:49:49 -0700,
> "David G. Johnston" wrote:
>
> >> And could someone help (take over if possible) writing a
> >> document for
Hi,
On 2025-03-25 13:07:49 +1300, Thomas Munro wrote:
> On Tue, Mar 25, 2025 at 11:55 AM Andres Freund wrote:
> > #define READ_STREAM_USE_BATCHING 0x08
>
> +1
>
> I wonder if something more like READ_STREAM_CALLBACK_BATCHMODE_AWARE
> would be better, to highlight that you are making a declarati
On Mon, Mar 24, 2025 at 3:15 PM Tom Lane wrote:
> FWIW, I share these doubts about whether these values are useful
> enough to include in the default EXPLAIN output. My main beef
> with them though is that they are basically numbers derived along
> the way to producing a cost estimate, and I don
On Tue, Mar 25, 2025 at 11:55 AM Andres Freund wrote:
> If a callback may sometimes need to block, it can still opt into
> READ_STREAM_USE_BATCHING, by submitting all staged IO before blocking.
>
> The hardest part is to explain the flag. Here's my current attempt:
>
> /* ---
> * Opt-in to using
On Sun, Mar 23, 2025 at 10:13 AM Andres Freund wrote:
>
> Hi,
>
> On 2025-03-23 01:45:35 -0700, Masahiko Sawada wrote:
> > Another idea is that parallel workers don't exit phase 1 until it
> > consumes all pinned buffers in the queue, even if the memory usage of
> > TidStore exceeds the limit.
>
>
On Fri, Mar 21, 2025 at 2:42 PM Alena Rybakina
wrote:
> On 13.03.2025 09:42, Bertrand Drouvot wrote:
>
> Hi,
>
> On Wed, Mar 12, 2025 at 05:15:53PM -0500, Jim Nasby wrote:
>
> The usecase I can see here is that we don't want autovac creating so much
> WAL traffic that it starts forcing other back
Lukas Fittl writes:
> The main argument I had initially when proposing this, is that Memoize is
> different from other plan nodes, in that it makes the child node costs
> "cheaper". Clearly seeing the expected cache hit/ratio (that drives that
> costing modification) helps interpret why the planne
"Euler Taveira" writes:
> I think those modules without control file, it is natural to use PG_VERSION.
> However, I'm concerned that users can confuse the version if we provide
> PG_VERSION as version and the extension catalog says something different.
Maybe, but the values will be sufficiently d
David Rowley writes:
> I'm not following what the -1 is for. Is it for showing both hit and
> evict ratios? And your vote is only for adding hit ratio?
> Just to make it clear, the evict ratio isn't redundant because we show
> hit ratio. If you have 1000 calls and 1000 distinct values and enough
On Mon, Mar 24, 2025 at 02:36:05PM -0500, Sami Imseih wrote:
>> Ideally we can also land the jumble funcs work in the other thread
>> to allow extensions to re-use the
>> in-core logic for jumbling expressions found in plan node trees.
>
> IIUC, there should be a refactor I am working on at this
On Tue, 25 Mar 2025 at 10:23, Andrei Lepikhov wrote:
>
> On 3/23/25 22:16, David Rowley wrote:
> > Once again, I'm not necessarily objecting to hit and evict ratios
> > being shown, I just want to know they're actually useful enough to
> > show and don't just bloat the EXPLAIN output needlessly. S
On Mon, Mar 24, 2025 at 11:12 AM Nikolay Shaplov wrote:
> Nobody would guess that
>
> ALTER TABLE test SET (vacuum_truncate=false);
> means "off"
>
> and
> ALTER TABLE test RESET (vacuum_truncate);
> means "system_default"
>
> This will lead to a lot of confusion.
I agree that this confuses peopl
Oh, one other thing: pg_getnameinfo_all is perfectly capable of
dealing with a Unix-socket address, so I think you should drop
the tests on ss_family and let pg_getnameinfo_all be in charge
of producing "[local]" for that case.
regards, tom lane
On Fri, Mar 21, 2025 at 08:54:55AM -0700, David G. Johnston wrote:
> I'm still partial to mine but yours probably fits the overall style of the
> codebase better.
Committed with some light edits.
--
nathan
On Mon, Mar 24, 2025 at 12:14 PM Melanie Plageman
wrote:
>
> This is the patch I intend to commit to fix this assuming my CI passes
> and there are no objections.
And pushed in aea916fe555a3
- Melanie
On Mon, Mar 24, 2025 at 1:16 PM Peter Eisentraut wrote:
>
> On 21.03.25 19:24, Matheus Alcantara wrote:
> > On Fri, Mar 21, 2025 at 1:28 PM Jacob Champion
> > wrote:
> >>
> >> Great, thank you! Looking over v10, I think I've run out of feedback
> >> at this point. Marked Ready for Committer.
> >
В письме от понедельник, 24 марта 2025 г. 23:04:39 MSK пользователь Nathan
Bossart написал:
> > We can have isset_offset, but then we have redesign all options with
> > custom unset behavior to use it, instead of unreachable default value.
> > This will make it consistent then.
>
> I don't see an
On Mon, Mar 24, 2025 at 10:35:41PM +0300, Nikolay Shaplov wrote:
> We can have isset_offset, but then we have redesign all options with
> custom unset behavior to use it, instead of unreachable default value.
> This will make it consistent then.
I don't see any reason why we are compelled to redes
> Ideally we can also land the jumble funcs work in the other thread to allow
> extensions to re-use the
> in-core logic for jumbling expressions found in plan node trees.
IIUC, there should be a refactor I am working on at this moment to make that
possible [0]
>> > FWIW, Lukas did start a Wiki
В письме от понедельник, 24 марта 2025 г. 22:26:17 MSK пользователь Nathan
Bossart написал:
> > And second general idea: changing engine is bad, at least when you can
> > manage without changing it.
>
> You have asserted this a couple of times without providing any reasons why.
> I know of no ge
Hi,
Please find the attached updated and rebased patch.
I have added a test in the test_dsa module that uses a function
to create a dsa area. This function is called after
the resowner->releasing is set to true, using an injection point.
Thank you,
Rahila Syed
v2-0001-Prevent-the-error-on-creat
> Hi! I started reviewing it and noticed that your code repeated this
> cycle maybe it would be better to put it in a separate function, for
> example in the form of a name like "analyze_stmts"?
>
> or is it possible to create a macro for them?
Perhaps it may be better to stick this all in a macro
В письме от понедельник, 24 марта 2025 г. 21:45:27 MSK пользователь Nathan
Bossart написал:
> * We'd need to decide what to say on the documentation side. My first
> instinct is that we should just leave it as "boolean" because otherwise
> we're going to describe something that sounds an awfu
On Mon, Mar 24, 2025 at 2:45 PM Nathan Bossart wrote:
> * I don't think this matches the parse_bool() behavior exactly. For
> example, parse_bool() appears to accept inputs like "t" to mean "true".
> This is also probably not a huge deal.
It's not great. We allow t/f in most places and some
On Mon, Mar 24, 2025 at 06:34:45PM +0700, John Naylor wrote:
> On Sat, Mar 22, 2025 at 10:42 AM Nathan Bossart
> wrote:
>> * 0002 introduces the Neon implementation, which conveniently doesn't need
>> configure-time checks or function pointers. I noticed that some
>> compilers (e.g., Apple cl
On Sun, Mar 23, 2025 at 9:43 PM Michael Paquier wrote:
> So I've applied the patch for now, to start with
> something.
>
Thanks for committing that, I think that's a great starting point for 18!
Ideally we can also land the jumble funcs work in the other thread to allow
extensions to re-use the
On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь Nathan
> Bossart написал:
>
>> For the sake of discussion, here is what the enum approach would look like.
>
> In my point of view this solution is much-much bet
В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь Nathan
Bossart написал:
> For the sake of discussion, here is what the enum approach would look like.
In my point of view this solution is much-much better: it achieves all goals,
has no drawbacks, and do not change reloption e
On Mon, Mar 24, 2025 at 9:41 AM Nathan Bossart
wrote:
> TBH I'm not understanding the pushback for adding a way to determine
> whether the storage parameter is actually set. It's very simple, and it
> seems like it could be useful elsewhere.
IMO this is superior to using sentinel values for th
On Thu, 20 Mar 2025 at 23:39, Mahendra Singh Thalor
wrote:
>
> On Thu, 30 Jan 2025 at 16:47, Srinath Reddy wrote:
> >
> >
> >
> > On Wed, Jan 29, 2025 at 9:55 PM Mahendra Singh Thalor <
mahi6...@gmail.com> wrote:
> >>
> >> Hi,
> >> While doing some testing with pg_dumpall, I noticed one weird
beh
On Mon, Mar 24, 2025, at 12:54 PM, Tom Lane wrote:
> Robert Haas writes:
> > It looks reasonable to me. I am a bit worried that using PG_VERSION as
> > the version string is going to feel like the wrong thing at some
> > stage, but I can't really say why, and I think it's better to do
> > somethin
On Mon, Mar 24, 2025 at 12:29 PM Alvaro Herrera wrote:
> > Again, I'm not 100% positive that changing the Boolean column to a
> > three-valued column is the right way forward, but it does have the
> > advantage of saving a byte, and the width of system catalog tables has
> > been a periodic concer
В письме от понедельник, 24 марта 2025 г. 20:37:50 MSK пользователь David G.
Johnston написал:
> My main concern when first seeing this was adding an integer to every
> single option in the entire system for something that is going to be zero
> 99.9% of the time. A bit bloated but not directly i
David Rowley writes:
> ... The main
> thing I'd like to understand here is if there's not enough time to get
> the entire patch set committed, is there much benefit to just having
> the EquivalenceMember index stuff in by itself without the
> RestrictInfo changes.
I finally made some time to look
For the sake of discussion, here is what the enum approach would look like.
--
nathan
>From f108e6c7e07c4148f097fbfd612cf79db60c5acd Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 24 Mar 2025 12:46:26 -0500
Subject: [PATCH 1/1] change vacuum_truncate relopt to enum
---
src/backend/ac
On Mon, Mar 24, 2025 at 1:27 PM Nikolay Shaplov wrote:
> > > You've just changed the whole engine, for what is seems to be an
> > > exceptional case, that can be solved via existing means.
> > I have not changed the whole engine. I have added an optional integer
> > field to a single struct.
>
>
В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь Nikolay
Shaplov написал:
> PS. I've just looked at code for vacuum_index_cleanup it has very same
> logic, just replace "auto" with anything you like, and uses enum.
> Grep for StdRdOptIndexCleanupValues for more info
I thought
On Mon, Mar 24, 2025 at 11:54 AM Tom Lane wrote:
> If somebody thinks of a better idea and is willing to do the legwork
> to make it happen, we can surely change to something else later on.
> Or invent another field with different semantics, or whatever.
Yeah, my thoughts exactly.
--
Robert Haa
В письме от понедельник, 24 марта 2025 г. 20:09:23 MSK пользователь Nathan
Bossart написал:
> > You've just changed the whole engine, for what is seems to be an
> > exceptional case, that can be solved via existing means.
> I have not changed the whole engine. I have added an optional integer
>
On Mon, Mar 24, 2025 at 07:53:43PM +0300, Nikolay Shaplov wrote:
> You've just changed the whole engine, for what is seems to be an exceptional
> case, that can be solved via existing means.
I have not changed the whole engine. I have added an optional integer
field to a single struct.
--
nath
В письме от понедельник, 24 марта 2025 г. 19:58:38 MSK пользователь Nathan
Bossart написал:
> On Mon, Mar 24, 2025 at 09:40:24AM -0700, David G. Johnston wrote:
> > So, given the precedent of vacuum_index_cleanup and the above, we should
> > turn this into an enum that accepts all existing boolean
On Mon, Mar 24, 2025 at 09:40:24AM -0700, David G. Johnston wrote:
> So, given the precedent of vacuum_index_cleanup and the above, we should
> turn this into an enum that accepts all existing boolean literal inputs and
> also has a undocumented "unset" default value that the user is not allowed
>
Alexander Korotkov писал(а) 2025-03-24 11:49:
On Mon, Mar 24, 2025 at 9:07 AM Alexander Pyhalov
wrote:
Alexander Korotkov писал(а) 2025-03-24 04:21:
> Hi, Alexander!
>
> On Tue, Mar 18, 2025 at 6:04 PM Alexander Pyhalov
> wrote:
>> This shouldn't. When semi-join is found below left/right join,
В письме от понедельник, 24 марта 2025 г. 19:41:27 MSK пользователь Nathan
Bossart написал:
> But more importantly, it allows
> us to more closely match the behavior of the existing reloptions with GUCs,
> and it prevents type mismatches (e.g., the reloption is an enum but the GUC
> is a Boolean).
В письме от понедельник, 24 марта 2025 г. 19:00:51 MSK пользователь Álvaro
Herrera написал:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
In my opinion it should.
"no new mechanism" is goo
Hello
I don't understand why this shouldn't work exactly like
vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
no new mechanism.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A.
On Mon, Mar 24, 2025 at 05:00:51PM +0100, Álvaro Herrera wrote:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
I explained my reasons for not proceeding with that approach upthread [0].
I don'
On Mon, Mar 24, 2025 at 5:42 AM Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь
> Nikolay
> Shaplov написал:
>
> > PS. I've just looked at code for vacuum_index_cleanup it has very same
> > logic, just replace "auto" with anything you like, and uses en
"David G. Johnston" writes:
> In discussing vacuum_truncate_set it occurs to me there is no SQL way for
> someone to easily view the current setting (or unset status) of a
> reloption. Seems like we could modify SHOW to cover this use case.
That seems like a pretty awful idea; for starters, ther
On Mon, Mar 24, 2025 at 9:08 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Mar 24, 2025 at 9:00 AM Álvaro Herrera
> wrote:
>
>> Hello
>>
>> I don't understand why this shouldn't work exactly like
>> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
>> n
On 2025-Mar-24, Robert Haas wrote:
> I mean, maybe there's an argument that some changes are more
> disruptive than others. For instance, if removing attndims would force
> drivers to run extra more complicated queries to learn whether a
> certain type is an array type, one could argue that taking
1 - 100 of 170 matches
Mail list logo
