Hi,
On Mon, Jul 21, 2025 at 10:52:12PM +0200, Christoph Berg wrote:
> Re: Tomas Vondra
> > >>> Submitted: https://marc.info/?l=linux-mm&m=175077821909222&w=2
> > >>>
> > >>
> > >> Thanks! Now we wait ...
> > >
> > > It looks like that the bug is "confirmed" and that it will be fixed:
> > > https:
On Mon, Jul 21, 2025 at 11:48:27AM +0300, Aleksander Alekseev wrote:
> +/* Check for NULL to prevent segfault */
> +if (con->name != NULL && strcmp(connection_name, con->name) == 0)
> break;
I have spent some time rechecking the whole code, and I have
backp
On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> The patch supports the getrandom() function as a new source of
> pg_strong_random(). The getrandom() function uses the same source as
> the /dev/urandom device but it seems much faster than opening,
> reading, and closing /dev/urand
On 2025-07-22, Fujii Masao wrote:
> The buildfarm member indri reported the following error, which seems related
> to
> the recent changes in dblink. I'll investigate this later.
Ah yes — contrib doesn't have gettext support and macOS doesn't like that.
Maybe removing the gettext_noop calls in
On Tue, Jul 22, 2025 at 3:36 PM Michael Paquier wrote:
>
> On Thu, Jul 17, 2025 at 01:34:42PM +0800, Japin Li wrote:
> > On Wed, 16 Jul 2025 at 10:08, Peter Smith wrote:
> >> What's going on there? Is it just an accidentally missing "/* can be
> >> NULL */" comment?
> >
> > It appears commit c1ec
On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier wrote:
>
> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> > The patch supports the getrandom() function as a new source of
> > pg_strong_random(). The getrandom() function uses the same source as
> > the /dev/urandom device but i
Hello
I started to read through 0001 and my first reaction is that I would
like to make a few more breaking changes. It appears that the current
patch tries to keep things unchanged, or to keep some things with the
CLUSTER name. I'm going to try and get rid of that. For instance, in
the grammar
Hi hackers,
Starting with PostgreSQL 17, pg_basebackup supports incremental
backups. However, the pg_stat_progress_basebackup view doesn't
currently show the backup type (i.e., whether it's a full or
incremental backup).
Therefore, I propose adding a backup_type column to this view. While
this in
On Fri, 18 Jul 2025 17:07:53 +0900
Rintaro Ikeda wrote:
> Hi,
>
> On 2025/07/16 22:49, Yugo Nagata wrote:
> >> I think we should also change the error message in pg_log_error. I
> >> modified the
> >> patch v8-0003 as follows:
> >> @@ -3383,8 +3383,8 @@ readCommandResponse(CState *st, MetaComma
On Sat, Jul 19, 2025 at 4:17 PM Shlok Kyal wrote:
>
> On Mon, 30 Jun 2025 at 16:25, shveta malik wrote:
> >
> > Few more comments on 002:
> >
> > 5)
> > +GetAllTablesPublicationRelations(Oid pubid, bool pubviaroot)
> > {
> >
> > + List*exceptlist;
> > +
> > + exceptlist = GetPublicationRelat
Just a quick historical note:
Back in 2016 [1], Andres had raised similar concerns about executor
overhead from deforming unneeded columns, but at the time
(pre-ExprEvalStep), expression evaluation wasn’t yet structured enough
for that overhead to show up clearly in profiles. I see that Tom
replie
On Wed, Jul 23, 2025 at 1:39 PM Joel Jacobson wrote:
> In their patch, in asyn.c's SignalBackends(), they do
> SendInterrupt(INTERRUPT_ASYNC_NOTIFY, procno) instead of
> SendProcSignal(pid, PROCSIG_NOTIFY_INTERRUPT, procnos[i]). They don't
> seem to check if the backend is already signalled or not
Hi, Peter
On Tue, 22 Jul 2025 at 17:46, Peter Smith wrote:
> Hi.
>
> Here are the latest v14 patches.
>
> Changes include:
>
> PATCH 0002.
> - Fixes the enable_seqscan PANIC bug reported by Japin [1]
> - Adds a new regression test case for this
>
> ==
> [1]
> https://www.postgresql.org/mess
Hello Kuroda-san,
20.07.2025 11:00, Alexander Lakhin wrote:
Yeah, I made a simple test for GetSystemTimePreciseAsFileTime() and
confirmed that in my VM it provides sub-microsecond precision. Regarding
NTP, I think the second failure of this ilk [1] makes this cause close to
impossible. (Can't w
On Thu, Jul 17, 2025, at 09:43, Joel Jacobson wrote:
> On Wed, Jul 16, 2025, at 02:20, Rishu Bagga wrote:
>> If we are doing this optimization, why not maintain a list of backends
>> for each channel, and only wake up those channels?
>
> Thanks for a contributing a great idea, it actually turned ou
On Tue, Jul 22, 2025 at 8:12 PM Japin Li wrote:
...
> 1.
> I encountered another crash while checking VCI's internal relations.
>
> rm -rf demo
> initdb -D demo
> cat shared_preload_libraries = 'vci'
> max_worker_processes = '20'
> EOF
>
> pg_ctl -D demo start
>
> cat
On Tue, 22 Jul 2025 at 14:36, Michael Paquier wrote:
> On Thu, Jul 17, 2025 at 01:34:42PM +0800, Japin Li wrote:
>> On Wed, 16 Jul 2025 at 10:08, Peter Smith wrote:
>>> What's going on there? Is it just an accidentally missing "/* can be
>>> NULL */" comment?
>>
>> It appears commit c1ec02be1d79
On Wed, Jul 23, 2025 at 3:51 AM Masahiko Sawada wrote:
>
> I've reviewed the 0001 patch and it looks good to me.
>
Thanks, I have pushed the 0001 patch.
The patch still
> has XXX comments at several places. Do we want to keep all of them
>
Yes, those are primarily the ideas for future optimiza
On Wed, Jul 23, 2025 at 1:58 PM Japin Li wrote:
>
>
> Hi, Peter
>
> On Tue, 22 Jul 2025 at 17:46, Peter Smith wrote:
> > Hi.
> >
> > Here are the latest v14 patches.
> >
> > Changes include:
> >
> > PATCH 0002.
> > - Fixes the enable_seqscan PANIC bug reported by Japin [1]
> > - Adds a new regres
On Tue, 22 Jul 2025 at 18:43, Fujii Masao wrote:
>
> On Tue, Jul 22, 2025 at 9:49 PM Álvaro Herrera wrote:
> >
> > On 2025-Jul-22, Fujii Masao wrote:
> >
> > > On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera
> > > wrote:
> >
> > > > Oh yeah, I should have remembered this -- see commit 213c959a29
On Tue, Jul 22, 2025 at 02:52:49PM -0500, Sami Imseih wrote:
>> We will need a field to store an enum. let's call it CachedPlanType
>> with the types of cached plan. We need to be able to differentiate
>> when cached plans are not used, so a simple boolean is not
>> sufficient.
Guess so.
>> We ca
Hi hackers,
While working on [1] I found the point. When recovery_target_lsn is specified
and
recovery_target_inclusive is false, recoveryStopsAfter() cannot return true.
```
/* Check if the target LSN has been reached */
if (recoveryTarget == RECOVERY_TARGET_LSN &&
On Tue, Jul 22, 2025 at 03:28:24PM -0500, Sami Imseih wrote:
> I know Michael opposed the idea of carrying these structures,
> at least CachedPlan, to Executor hooks ( or maybe just not QueryDesc?? ).
> It will be good to see what he think, or if others an opinion about this,
> about
> adding a po
On Wed, 23 Jul 2025 at 11:06, Tom Lane wrote:
>
> David Rowley writes:
> > I'm currently thinking we should just fix the pgmkdirp.c instance and
> > call it good.
>
> +1
Done.
David
Hi,
On 2025-07-22 19:13:23 -0400, Peter Geoghegan wrote:
> On Tue, Jul 22, 2025 at 6:53 PM Andres Freund wrote:
> > That may be true with local fast NVMe disks, but won't be true for networked
> > storage like in common clouds. Latencies of 0.3 - 4ms leave a lot of CPU
> > cycles for actual proce
On Mon, Jul 21, 2025 at 2:38 PM Japin Li wrote:
>
>
> Hi, hackers,
>
> I was recently reviewing the KeepFileRestoredFromArchive() function and came
> across a section that raised a question for me:
>
> /*
> * Create .done file forcibly to prevent the restored segment from being
> * a
On Tue, Jul 22, 2025 at 5:11 PM Andres Freund wrote:
> On 2025-07-18 23:25:38 -0400, Peter Geoghegan wrote:
> > > To some degree the table AM will need to care about the index level
> > > batching -
> > > we have to be careful about how many pages we keep pinned overall. Which
> > > is
> > > som
On 7/22/25 23:35, Peter Geoghegan wrote:
> On Tue, Jul 22, 2025 at 4:50 PM Tomas Vondra wrote:
>>> Obviously, whatever advantage that the "complex" patch has is bound to
>>> be limited to cases where index characteristics are naturally the
>>> limiting factor. For example, with the pgbench_account
On Wed, 23 Jul 2025 at 02:35, Andrei Lepikhov wrote:
> The 'Buffers:' way looks more natural to me. I don't like duplicated
> text in the explain format - it is already cluttered by multiple
> unnecessary elements that distract attention from the problematic plan
> elements, such as unplaggable co
On Tue, Jul 22, 2025 at 8:08 PM Andres Freund wrote:
> My response was specific to Tomas' comment that for many queries, which tend
> to be more complicated than the toys we are using here, there will be CPU
> costs in the query.
Got it. That makes sense.
> cheaper query
On 7/23/25 02:39, Peter Geoghegan wrote:
> On Tue, Jul 22, 2025 at 8:08 PM Andres Freund wrote:
>> My response was specific to Tomas' comment that for many queries, which tend
>> to be more complicated than the toys we are using here, there will be CPU
>> costs in the query.
>
> Got it. That m
On Mon, 21 Jul 2025 at 06:27, Greg Hennessy wrote:
> test=# show parallel_worker_algorithm ;
> parallel_worker_algorithm
> ---
> log3
> (1 row)
I don't think having a GUC which allows exactly two settings is
anywhere near as flexible as you could make this. You're compla
On Tue, Jul 22, 2025 at 10:57:06AM -0400, Andres Freund wrote:
> It seems rather unsurprising that that causes a slowdown.
>
> The pre-check is there to:
> /* Don't expend a clock check if nothing to do */
>
> but you made it way more expensive than a clock check would have been (not
> coun
Hello Alexander,
> Nagata-san, could you please share the configuration of hamerkop? If it's
> running inside VM, what virtualization software is used?
>
> [1]
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2025-07-09%2011%3A02%3A23
I am not the person in charge of it, s
Hi,
On 2025-07-23 02:50:04 +0200, Tomas Vondra wrote:
> But I don't see why would this have any effect on the prefetch distance,
> queue depth etc. Or why decreasing INDEX_SCAN_MAX_BATCHES should improve
> that. I'd have expected exactly the opposite behavior.
>
> Could be bug, of course. But it'
On Tue, Jul 22, 2025 at 02:25:13PM -0500, Nathan Bossart wrote:
> I stared at this patch some more and came up with the attached. The
> biggest change is that I've moved the list of built-in LWLock tranches to
> the existing lwlocklist.h file. That simplifies the patch and centralizes
> these lis
I further tested inherited tables flow as well wrt ONLY and EXCEPT, it
works well. But while reading docs for the saem, I have few concerns.
1)
While explaining ONLY for EXCEPT, create-publication doc says this
+ This does not apply to a partitioned table, however. The partitions of
+
On Mon, Jul 21, 2025 at 6:59 PM Ajin Cherian wrote:
>
> Yes, this is correct. I have also verified this in my testing that
> when there is a second subscription, a deadlock can still happen with
> my previous patch. I have now modified the patch in tablesync worker
> to take locks on both Subscrip
Dear Alexander,
> And here it is [1]:
> diff --strip-trailing-cr -U3
> c:/build-farm-local/buildroot/HEAD/pgsql/src/test/isolation/expected/stats.ou
> t
> c:/build-farm-local/buildroot/HEAD/pgsql.build/testrun/isolation/isolation/res
> ults/stats.out
> ---
> c:/build-farm-local/buildroot/HEAD/pgsq
On Tue, Jul 22, 2025 at 5:03 AM Masahiko Sawada wrote:
>
> Yes, I agree. The main patch focuses on the part where we
> automatically change the effective WAL level upon the logical slot
> creation and deletion (and potentially remove 'logical' from
> wal_level), and other things are implemented as
On Tue, Jul 22, 2025 at 7:33 PM Vitale, Anthony, Sony Music
wrote:
>
> Yes, it is exactly what I am looking for
>
> However, it appears that this patch (The Ability to create server with FOR
> CONNECTION ONLY) was never implemented OR at least I can't find it.
>
> Do you know if there is any way
On Mon Jul 21, 2025 at 7:11 PM -03, Vik Fearing wrote:
> That is my preferred grammar, thank you.
>
Thanks for confirming!
> I have not looked at the C code by this can be obtained with a syntax
> transformation. To wit:
> SELECT a, b, c
> FROM tab
> QUALIFY wf() OVER () = ?
>
>
> can be rewritt
> locked. I've made a new version of the patch on PG_15.
I've made a similar fix on HEAD just so that the code is now
consistent. I don't think the similar problem (deadlock between two
different subscriptions trying to drop tracking origin) occurs on
HEAD with my previous patch, as the way origi
On 22/07/2025 14:26, Vik Fearing wrote:
The is:
::=
ERROR
| NULL
| DEFAULT
but I am planning on removing the NULL variant in favor of having the
be a . So
it would be either ERROR ON CONVERSION ERROR (postgres's current
behavior), or DEFAULT NULL ON CONVERSION ERROR.
Sorry
On Mon, Jul 21, 2025, at 08:16, Joel Jacobson wrote:
> Since there is no point of just doing NOTIFY if nobody is LISTENing,
> a realistic benchmark would also need to do LISTEN.
> What you will then see is that TPS will be severely impacted,
> and the gains from removing the global exclusive lock w
On 2025-Jul-22, Fujii Masao wrote:
> On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera wrote:
> > Oh yeah, I should have remembered this -- see commit 213c959a294d. Feel
> > free to do away with the whole translation thing ... doesn't seem worth
> > spending more time on it.
>
> Yes! The attached
On Tue, Jul 22, 2025 at 9:30 PM Andrei Lepikhov wrote:
>
> On 22/7/2025 07:22, Fujii Masao wrote:
> > Log remote NOTICE, WARNING, and similar messages using ereport().
> >
> > Previously, NOTICE, WARNING, and similar messages received from remote
> > servers over replication, postgres_fdw, or dbli
On Tue, Jul 22, 2025 at 1:24 PM Nikita Malakhov wrote:
>
> Hi Michael!
>
> Yes, I know about relation rewrite and have already thought about how
> we can avoid excessive storage of toastrelid and do not spoil rewrite,
> still do not have a good enough solution.
The high-level idea would be to any
Hi,
On 2025-07-10 21:00:21 +0200, Matthias van de Meent wrote:
> On Wed, 9 Jul 2025 at 16:59, Andres Freund wrote:
> > On 2025-07-09 13:26:09 +0200, Matthias van de Meent wrote:
> > > I've been going through the new AIO code as an effort to rebase and
> > > adapt Neon to PG18. In doing so, I foun
On 22/7/2025 14:49, Álvaro Herrera wrote:
On 2025-Jul-22, Fujii Masao wrote:
We should still remove all gettext_noop() markers in contrib :-)
You mean to remove gettext_noop() also from basic_archive.c?
Yes, it's useless and misleading. Feel free to do it in the same commit ...
Just for t
On Tue, Jul 22, 2025 at 6:24 PM Álvaro Herrera wrote:
>
> On 2025-Jul-22, Álvaro Herrera wrote:
>
> > On 2025-07-22, Fujii Masao wrote:
> >
> > > The buildfarm member indri reported the following error, which seems
> > > related to
> > > the recent changes in dblink. I'll investigate this later.
On 22/7/2025 01:22, Sami Imseih wrote:
Note: the size of the change in pg_stat_statements--1.12--1.13.sql
points that we should seriously consider splitting these attributes
into multiple sub-functions.
So we don't lose track of this. This should be a follow-up thread. I do
agree something has
On 22/7/2025 01:07, Michael Paquier wrote:
On Mon, Jul 21, 2025 at 04:47:31PM -0500, Sami Imseih wrote:
Last week I published a v11 that adds a field to QueryDesc, but as I thought
about this more, how about we just add 2 bool fields in QueryDesc->estate
( es_cached_plan and es_is_generic_plan )
On Tue, Jul 22, 2025 at 2:45 PM Vik Fearing wrote:
>
> It was accepted into the standard after 2023 was released. I am the
> author of this change in the standard, so feel free to ask me anything
> you're unsure about.
>
is the generally syntax as mentioned in this thread:
CAST(source_expression
hi.
src/backend/utils/misc/guc_tables.c:
static const struct config_enum_entry icu_validation_level_options[] = {
{"disabled", -1, false},
{"debug5", DEBUG5, false},
{"debug4", DEBUG4, false},
{"debug3", DEBUG3, false},
{"debug2", DEBUG2, false},
{"debug1", DEBUG1, false},
On Mon, Jul 21, 2025 at 9:29 PM Peter Geoghegan wrote:
>
> On Thu, Jul 17, 2025 at 7:27 PM Mihail Nikalayeu
> wrote:
> > > FWIW _hash_readpage has a comment about a stashed LSN, so it seems as
> > > if this was barely missed by the work on hash indexes around 2017:
> >
> > I think commit 22c5e73
On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera wrote:
>
> On 2025-Jul-22, Fujii Masao wrote:
>
> > Is the issue caused by the use of _() in libpq-be-fe-helpers.h,
> > instead of using gettext_noop() in dblink.c? At least in my test
> > environment, the build error disappeared after applying
> > th
Hi,
On Fri, Jul 18, 2025 at 11:43:47AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-07-18 06:04:38 +, Bertrand Drouvot wrote:
> > Here what I’ve done:
> >
> > 1. Added 2 probes: one in pgstat_report_wait_start() and one in
> > pgstat_report_wait_end()
> > to measure the wait events duration
On 22/07/2025 12:19, jian he wrote:
On Tue, Jul 22, 2025 at 2:45 PM Vik Fearing wrote:
It was accepted into the standard after 2023 was released. I am the
author of this change in the standard, so feel free to ask me anything
you're unsure about.
is the generally syntax as mentioned in thi
On 22/7/2025 00:17, David Rowley wrote:
On Fri, 4 Jul 2025 at 20:30, Ilia Evdokimov
wrote:
I attached rebased v10 patch on 5a6c39b.
I've gone over this and made some cosmetic adjustments. A few
adjustments to the comments and used Cardinality rather than double
for some data types. I also mov
On 2025-Jul-22, Álvaro Herrera wrote:
> On 2025-07-22, Fujii Masao wrote:
>
> > The buildfarm member indri reported the following error, which seems
> > related to
> > the recent changes in dblink. I'll investigate this later.
>
> Ah yes — contrib doesn't have gettext support and macOS doesn't
On Tue, 22 Jul 2025 at 17:46, Peter Smith wrote:
> Hi.
>
> Here are the latest v14 patches.
>
> Changes include:
>
> PATCH 0002.
> - Fixes the enable_seqscan PANIC bug reported by Japin [1]
> - Adds a new regression test case for this
>
> ==
> [1]
> https://www.postgresql.org/message-id/ME0P3
Shlok, I was trying to validate the interaction of
'publish_via_partition_root' with 'EXCEPT". Found some unexpected
behaviour, can you please review:
Pub:
-
CREATE TABLE tab_root (range_col int,i int,j int) PARTITION BY RANGE
(range_col);
CREATE TABLE tab_part_1 PARTITION OF tab_root FOR
On Thu, Jul 17, 2025 at 1:41 AM Dagfinn Ilmari Mannsåker
wrote:
>
> Hi hackers,
>
> These two patches are split out from my earlier thread about improving
> tab completion for varous RESET forms
> (https://postgr.es/m/87bjqwwtic@wibble.ilmari.org), so that the bug
> fixes can be tracked as an
Hi, Andrey!
Thank you for working on this! There is a long history of the patch, I
hope it will be committed soon!)
On Fri, Jul 11, 2025 at 3:39 PM Andrey Borodin wrote:
>
>
>
> > On 30 Jun 2025, at 16:34, Andrey Borodin wrote:
> >
> > Please find attached two new steps for amcheck:
> > 1. A fu
Hi,
> I have spent some time rechecking the whole code, and I have
> backpatched this part. [...]
Many thanks!
> Hmm.. Aren't you missing a va_end(args) in the early exit you are
> adding here?
I do, and it's rather stupid of me. Thanks.
> [...]
> At the end, I finish with the attached, wher
On Tue, Jul 22, 2025 at 9:49 PM Álvaro Herrera wrote:
>
> On 2025-Jul-22, Fujii Masao wrote:
>
> > On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera wrote:
>
> > > Oh yeah, I should have remembered this -- see commit 213c959a294d. Feel
> > > free to do away with the whole translation thing ... does
Hi,
I wanted to run some performance tests for [1] and looked at the profile of a
workload with a lot of short queries. And was rather surprised to see
pgstat_report_stat() to be the top entry - that certainly didn't use to be the
case.
For the, obviously rather extreme, workload of a pgbench ses
On 22/07/2025 17:14, Nico Williams wrote:
It doesn't seem too crazy that extra WHEREs in WHERE clauses should some
day function as ANDs, and ditto HAVINGs, which is another reason not to
reuse HAVING for this: just to leave that a possibility, remote though
it might be.
I have a firm finger o
On 2025-07-22 Tu 11:14 AM, Vik Fearing wrote:
I agree that its own clause is best; I just greatly dislike QUALIFY.
Sorry.
If we were making up our own syntax this would be a sensible thing to
debate. If we're talking about implementing something we expect to be in
the standard, I thi
On Tue, Jul 22, 2025 at 2:45 AM Vik Fearing wrote:
>
> On 22/07/2025 03:59, jian he wrote:
> > Based on my reading of [4], it seems CAST(EXPRESSION AS TYPE DEFAULT
> > def_expr ON ERROR)
> > is not included in SQL:2023.
> >
> > [4]
> https://peter.eisentraut.org/blog/2023/04/04/sql-2023-is-finish
There have been some complaints recently about how jsonb_agg()
is a lot slower than json_agg() [1]. That's annoying considering
that the whole selling point of JSONB is to have faster processing
than the original JSON type, so I poked into that. What I found
is that jsonb_agg() and its variants a
On Tue, Jul 22, 2025 at 1:35 PM Peter Geoghegan wrote:
> I attach pgbench_accounts_pkey_nhblks.txt, which shows a query that
> (among other things) ouputs "nhblks" for each leaf page from a given
> index (while showing the details of each leaf page in index key space
> order).
I just realized tha
On Tue, Jul 22, 2025 at 10:37 AM Tom Lane wrote:
> There have been some complaints recently about how jsonb_agg()
> is a lot slower than json_agg() [1]. That's annoying considering
> that the whole selling point of JSONB is to have faster processing
> than the original JSON type, so I poked into
On Tue, Jul 22, 2025 at 01:14:20AM -0400, Tom Lane wrote:
> Nico Williams writes:
> > On Mon, Jul 21, 2025 at 09:43:15PM -0600, Merlin Moncure wrote:
> >> Hm, HAVING requires to apply 'group by' which windows functions do not
> >> require (unlike aggregates).
>
> > Pavel's point is precisely to a
Hi,
While reviewing gist amcheck patch [1] I realized that brin amcheck
also must check if current snapshot is OK with index indcheckxmin (as
btree, gist do it). Currently this check is contained in btree amcheck
code, but other AMs need it for heapallindexed as well, so I moved it
from btree to v
> I would like to oppose to the current version a little.
>
> Commits de3a2ea3b264 and 1d477a907e63 introduced elements that are more
> closely related to the execution phase. While the parameter
> es_parallel_workers_to_launch could be considered a planning parameter,
> es_parallel_workers_launche
On Tue, Jul 22, 2025 at 9:06 AM Tomas Vondra wrote:
> Real workloads are likely to have multiple misses in a row, which indeed
> ramps up the distance quickly. So maybe it's not that bad. Could we
> track a longer history of hits/misses, and consider that when adjusting
> the distance? Not just th
I often accidentally write
SELECT .. WHERE .. WHERE ..;
which is obviously wrong, but what I mean when I do this is
SELECT .. WHERE .. AND ..;
and if I wrote GROUP BY .. HAVING queries as often as I do ones that
don't GROUP BY then I'd probably also accidentally use extra HAVINGs as
ANDs.
On 22/07/2025 17:07, Nico Williams wrote:
On Tue, Jul 22, 2025 at 01:14:20AM -0400, Tom Lane wrote:
Nico Williams writes:
On Mon, Jul 21, 2025 at 09:43:15PM -0600, Merlin Moncure wrote:
Hm, HAVING requires to apply 'group by' which windows functions do not
require (unlike aggregates).
Pave
On Mon, Jul 21, 2025 at 11:02:36PM -0600, Merlin Moncure wrote:
> On Mon, Jul 21, 2025 at 10:08 PM Nico Williams
> wrote:
> > I would have a HAVING clause that comes _before_ GROUP BY apply to
> > window functions and a second one that comes _after_ GROUP BY apply to
> > the grouping.
>
> I don't
Em ter., 22 de jul. de 2025 às 08:56, Matheus Alcantara <
matheusssil...@gmail.com> escreveu:
> The current patch supports the following syntaxes:
> SELECT a, b, c
> wf() OVER () as d
> FROM tab
> QUALIFY d = 1
> When using the "QUALIFY d = 1" form, I currently rewrite the expressi
> > This is already an established pattern has been used by other
> > RDBMS's. Having worked with such interface in the past, a combo of
> > ALTER and GUC, I never thought it was awkward and it's quite simple to
> > understand/maintain. But that is subjective.
> >
>
> It's amazing what people are w
On Tue, Jul 22, 2025 at 4:12 AM Dagfinn Ilmari Mannsåker
wrote:
>
> Masahiko Sawada writes:
>
> > On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier
> > wrote:
> >>
> >> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> >> > The patch supports the getrandom() function as a new so
On 7/21/25 14:35, Andres Freund wrote:
> Hi,
>
> On 2025-07-21 13:37:04 -0400, Greg Burd wrote:
>> On 7/18/25 13:03, Andres Freund wrote:
>> Hello. Thanks again for taking the time to review the email and patch,
>> I think we're onto something good here.
>>
>>> I'd be curious if anybody wants to a
On Mon, Jul 21, 2025 at 4:49 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-07-21 12:41:49 -0700, Masahiko Sawada wrote:
> > The reason why I added some callbacks as table AM callbacks in the
> > patch is that I could not find other better places. Currently,
> > vacuumparallel.c handles several criti
On Tue, Jul 22, 2025 at 11:32 AM Masahiko Sawada wrote:
> While getentropy() has better portability, according to the
> getentropy() manual, the maximum length is limited to 256 bytes. It
> works in some cases such as generating UUID data but seems not
> appropriate for our general pg_strong_rando
Corey Huinker писал(а) 2025-07-22 22:42:
On Sun, Jul 20, 2025 at 6:21 PM Dmitry Mityugov
wrote:
Code in src/port/pgmkdirp.c uses strstr() to find a single character
in
a string, but strstr() seems to be too generic for this job. Another
function, strchr(), might be better suited for this purp
On 22/07/2025 20:54, Matheus Alcantara wrote:
(this happens on transformQualifyClause() if you want to take a look)
I took a quick look at the patch (without applying and testing it) and
it seems to me that parse analysis is the wrong place to do this. We
want ruleutils to be able to spew
On Tue, Jul 22, 2025 at 4:50 PM Tomas Vondra wrote:
> > Obviously, whatever advantage that the "complex" patch has is bound to
> > be limited to cases where index characteristics are naturally the
> > limiting factor. For example, with the pgbench_accounts_pkey table
> > there are only ever 6 dist
On Wed, Jul 23, 2025 at 8:08 AM Joel Jacobson wrote:
> Previously, ProcSignal used an array of volatile sig_atomic_t flags, one
> per signal reason. A sender would set a flag and then unconditionally
> send a SIGUSR1 to the target process. This could result in a storm of
> redundant signals if mul
Greetings,
Patch attached
Dave Cramer
0001-replace-protocol-constants-with-named-constants-from.patch
Description: Binary data
On Wed, 23 Jul 2025 at 09:34, Dmitry Mityugov wrote:
> Thank you for your attention to this problem. The code in
> contrib/fuzzystrmatch/dmetaphone.c indeed uses several calls to strstr()
> to search for a single character, but it also uses strstr() to search
> for strings that consist of more tha
On Mon, Jul 21, 2025 at 8:49 PM Amit Kapila wrote:
>
> On Mon, Jul 21, 2025 at 11:27 PM Masahiko Sawada
> wrote:
> >
> > On Sun, Jul 20, 2025 at 9:00 PM Amit Kapila wrote:
> > >
> >
> > > If so, I agree
> > > with you, we don't need XIDs of other databases as logical WALSender
> > > will anyway
On Tue, Jul 22, 2025, at 23:54, Thomas Munro wrote:
> On Wed, Jul 23, 2025 at 8:08 AM Joel Jacobson wrote:
>> Previously, ProcSignal used an array of volatile sig_atomic_t flags, one
>> per signal reason. A sender would set a flag and then unconditionally
>> send a SIGUSR1 to the target process. T
On Wed, 23 Jul 2025 at 09:21, Vik Fearing wrote:
> I took a quick look at the patch (without applying and testing it) and
> it seems to me that parse analysis is the wrong place to do this. We
> want ruleutils to be able to spew out the QUALIFY clause as written in a
> view and not as transformed.
> Now wondering if it would be better to spend the effort looking at
> pg_hint_plan and seeing how hard it would be to get global hints added
> which are applied to all queries, and then add a way to disable use of
> a named index. (I don't have any experience with that extension other
> than looki
On Wed, 23 Jul 2025 at 10:36, Tom Lane wrote:
>
> David Rowley writes:
> > Looking at [1], it seems even ancient versions of gcc and clang
> > rewrite the strstr() into a strchr() call when the search term is a
> > single char string. So it might not be worth doing to any trouble
> > here.
>
> I
David Rowley writes:
> I'm currently thinking we should just fix the pgmkdirp.c instance and
> call it good.
+1
regards, tom lane
On Tue, Jul 22, 2025 at 6:53 PM Andres Freund wrote:
> That may be true with local fast NVMe disks, but won't be true for networked
> storage like in common clouds. Latencies of 0.3 - 4ms leave a lot of CPU
> cycles for actual processing of the data.
I don't understand why it wouldn't be a proble
1 - 100 of 148 matches
Mail list logo
