On Sat, 14 Sept 2024, 12:39 Tom Lane, wrote:
> Julien Rouhaud writes:
> > While adapting in pg_stat_kcache the fix for buggy nesting level
> calculation, I
> > noticed that one comment referencing the old approach was missed.
> Trivial
> > patch attached.
>
> Hmm ... I agree that para is out of
Julien Rouhaud writes:
> While adapting in pg_stat_kcache the fix for buggy nesting level calculation,
> I
> noticed that one comment referencing the old approach was missed. Trivial
> patch attached.
Hmm ... I agree that para is out of date, but is there anything to
salvage rather than just de
Hi,
(adding TOm in Cc as committer/co-author of the original patch)
While adapting in pg_stat_kcache the fix for buggy nesting level calculation, I
noticed that one comment referencing the old approach was missed. Trivial
patch attached.
>From 3ca50f1e66896c9ffd4eff8c151f98735b928219 Mon Sep 17
On Fri, Sep 13, 2024 at 7:51 PM Tomas Vondra wrote:
> Sure, an incremental sort can improve things if things go well, no doubt
> about that. But how significant can the improvement be, especially if we
> need to sort everything? In your example it's ~15%, which is nice, and
> maybe the benefits ca
On Fri, Sep 13, 2024 at 7:35 PM Tomas Vondra wrote:
> On 9/13/24 06:04, Richard Guo wrote:
> > It seems to me that some parts of our code assume that, for a given
> > input path that is partially ordered, an incremental sort is always
> > preferable to a full sort (see commit 4a29eabd1). Am I get
On Fri, Sep 13, 2024 at 03:26:42PM -0700, Andrew Kane wrote:
> This was my hunch as well since none of the source files changed. Also,
> neither function is present with `dumpbin /EXPORTS /SYMBOLS
> lib\postgres.lib`, which led me to believe it may need to be addressed
> upstream.
Hmm. Perhaps we
> Probably a Windows thing?
Correct, it's only on Windows.
> I do see a fair amount of special handling for f2s.c in the build files.
I
wonder if something got broken for Windows in the switch from the MSVC
scripts to meson.
This was my hunch as well since none of the source files changed. Also
On Wed, Sep 11, 2024 at 07:50:40PM +0200, Álvaro Herrera wrote:
> Hello,
>
> I noticed that these two items in the current notes are separate:
>
>
>
>
>
> Allow specification of partitioned table
> access methods (Justin Pryzby, Soumyadeep Chakraborty,
> Michael P
On Fri, Sep 13, 2024 at 06:41:30PM -0300, Marcos Pegoraro wrote:
> Em sex., 13 de set. de 2024 às 13:39, Bruce Momjian
> escreveu:
>
> I changed the patch to use the section symbol "§" instead of showing
> the hashes. The hashes seemed too detailed. Does anyone see a better
> symbol
Em sex., 13 de set. de 2024 às 13:39, Bruce Momjian
escreveu:
> I changed the patch to use the section symbol "§" instead of showing
> the hashes. The hashes seemed too detailed. Does anyone see a better
> symbol to use from here?
>
Robert and others liked commit hashes because you can do "git
On Fri, Sep 13, 2024 at 04:58:20PM -0400, Tom Lane wrote:
> Andrew Kane writes:
>> With Postgres 17 RC1 on Windows, `float_to_shortest_decimal_buf` and
>> `float_to_shortest_decimal_bufn` are not longer exported. This causes
>> `unresolved external symbol` linking errors for extensions that rely o
> On 13 Sep 2024, at 11:07 PM, Andrew Kane wrote:
>
> Hi,
>
> With Postgres 17 RC1 on Windows, `float_to_shortest_decimal_buf` and
> `float_to_shortest_decimal_bufn` are not longer exported. This causes
> `unresolved external symbol` linking errors for extensions that rely on these
> funct
On Fri, Sep 13, 2024 at 04:17:31PM -0400, Bruce Momjian wrote:
> Attached patch applied, with commit URL link.
Looks good, thanks.
--
nathan
Andrew Kane writes:
> With Postgres 17 RC1 on Windows, `float_to_shortest_decimal_buf` and
> `float_to_shortest_decimal_bufn` are not longer exported. This causes
> `unresolved external symbol` linking errors for extensions that rely on
> these functions (like pgvector). Can these functions be exp
On Wed, Sep 11, 2024 at 09:36:35AM -0500, Nathan Bossart wrote:
> On Wed, Sep 11, 2024 at 10:12:58AM -0400, Bruce Momjian wrote:
> > On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
> >> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio
> >> wrote:
> >> > For 1, I think adding the
Hi,
With Postgres 17 RC1 on Windows, `float_to_shortest_decimal_buf` and
`float_to_shortest_decimal_bufn` are not longer exported. This causes
`unresolved external symbol` linking errors for extensions that rely on
these functions (like pgvector). Can these functions be exported like
previous vers
On Sat, Sep 7, 2024 at 10:12:00AM +0800, jian he wrote:
> On Sat, Sep 7, 2024 at 6:30 AM Jelte Fennema-Nio wrote:
> >
> > On Thu, 22 Aug 2024 at 21:34, Marcos Pegoraro wrote:
> > > I understand your point, and agree with that for previous releases, but
> > > since we have a month only for versi
Can you lead me to a beginner friendly task so I can start hacking?
--
Siavosh Kasravi
* "Save a Tree" - Please print this email only if necessary.*
Hi,
On Fri, Sep 13, 2024 at 04:45:08PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> Thanks for working on this!
>
> Your patch applies and builds cleanly.
Thanks for looking at it!
> On Fri, 6 Sept 2024 at 18:03, Bertrand Drouvot
> wrote:
> >
> > - As stated up-thread, the pg_stat_get_backend_io
On Thu, Sep 12, 2024 at 10:41:27PM -0500, Nathan Bossart wrote:
> Thanks for checking. I'll commit this fix in the morning.
Committed.
--
nathan
On 2024/03/14 9:19, Alexander Korotkov wrote:
On Mon, Mar 11, 2024 at 11:48 AM Alexander Korotkov
wrote:
On Mon, Mar 11, 2024 at 5:43 AM Anton A. Melnikov
wrote:
On 11.03.2024 03:39, Alexander Korotkov wrote:
Now that we distinguish stats for checkpoints and
restartpoints, we need to upd
On Wed, Sep 11, 2024 at 09:00:33AM -0400, Robert Haas wrote:
> On Tue, Sep 10, 2024 at 4:58 PM Noah Misch wrote:
> > ... a rule of "each wait event appears in one
> > pgstat_report_wait_start()" would be a rule I don't want.
>
> As the original committer of the wait event stuff, I intended for th
Denis Garsh writes:
> The patch adds support for system columns in JOIN USING clause.
I think this is an actively bad idea, and it was likely intentional
that it's not supported today. A few reasons why:
* There are, fundamentally, no use-cases for joining on system
columns. The only one that
Hi.
in ExecutePlan
we have:
for (;;)
{
ResetPerTupleExprContext(estate);
slot = ExecProcNode(planstate);
if (!TupIsNull(slot))
{
if((slot != NULL) && (slot->tts_tupleDescriptor != NULL)
&& (slot->tts_tupleDescriptor->natts > 0)
On 12.09.24 22:01, Jeff Davis wrote:
On Mon, 2024-09-09 at 15:37 +0200, Peter Eisentraut wrote:
In the end, I figured the best thing to do here is to add an explicit
locale argument to MATCH_LOWER() and GETCHAR() so one can actually
understand this code by reading it. New patch attached.
Look
On Friday, September 13, 2024, David G. Johnston
wrote:
>
> Link to PR on GitHub: https://github.com/hilltracer/postgres/pull/3
>>
>
> You apparently missed the note on GitHub that says we don’t work with pull
> requests. Patches are to be submitted directly to the mailing list.
>
Sorry, I see
On Friday, September 13, 2024, Denis Garsh wrote:
>
>
> The patch adds support for system columns in JOIN USING clause.
>
Definitely not high on my list of oversights to fix. Resorting to the ON
clause for the rare query that would need to do such a thing isn’t that
costly. But as the patch exi
Hi,
Thanks for working on this!
Your patch applies and builds cleanly.
On Fri, 6 Sept 2024 at 18:03, Bertrand Drouvot
wrote:
>
> - As stated up-thread, the pg_stat_get_backend_io() behaves as if
> stats_fetch_consistency is set to none (each execution re-fetches counters
> from shared memory).
On 9/13/24 15:05, Andreas Karlsson wrote:
On 9/13/24 4:41 AM, Laurenz Albe wrote:
That's very broken and should not be allowed.
+1
A possible objection is that if anybody has such a setup and
hasn't noticed a problem because they never change their
timezone setting, they might not appreciate
On 9/13/24 4:41 AM, Laurenz Albe wrote:
That's very broken and should not be allowed.
+1
A possible objection is that if anybody has such a setup and
hasn't noticed a problem because they never change their
timezone setting, they might not appreciate us breaking it.
I hope that there are fe
On 9/10/24 10:54 AM, Daniel Gustafsson wrote:
On 22 Jul 2024, at 23:25, Andreas Karlsson wrote:
I have bench marked the two patches now and failed to measure any speedup or
slowdown from the first patch (removing return) but I think it is a good idea
anyway.
For the second patch (optimize st
On Thu, 12 Sept 2024 at 14:03, Ajin Cherian wrote:
>
> On Tue, Sep 3, 2024 at 7:42 PM vignesh C wrote:
>
> On Fri, 30 Aug 2024 at 11:01, Nisha Moond
> wrote:
> >
> > Here is the v11 patch-set. Changes are:
>
> 1) This command crashes:
> ALTER SUBSCRIPTION name RESET CONFLICT
Hi Alexander,
10.08.2024 20:18, Alexander Korotkov wrote:
On Sat, Aug 10, 2024 at 7:33 PM Alexander Korotkov wrote:
On Tue, Aug 6, 2024 at 5:17 AM Alexander Korotkov wrote:
...
Here is a revised version of the patchset. I've fixed some typos,
identation, etc. I'm going to push this once it
On Tue, 10 Sept 2024 at 09:45, Amit Kapila wrote:
>
> On Tue, Sep 10, 2024 at 2:51 AM Masahiko Sawada wrote:
> >
> > On Mon, Sep 9, 2024 at 2:38 AM Shubham Khanna
> > wrote:
> > >
> >
> > Thank you for updating the patches. I have some comments:
> >
> > Do we really need to add this option to te
On 9/13/24 13:18, Richard Guo wrote:
> On Mon, Sep 9, 2024 at 6:22 PM Tomas Vondra wrote:
>> I have not thought about this particular case too much, but how likely
>> is it that mergejoin will win for this plan in practice? If we consider
>> a query that only needs a fraction of rows (say, thanks
> The PPC asm code was originally written in 2002, and the first use of
> _ sync_lock_test_and_set(), for ARM, appeared in 2012. The commit that
> made __sync_lock_test_and_set() be chosen automatically for platforms
> that don't specify anything else was added in 2022.
Thanks for
Hello,
I would like to add the information of the PID that caused the failure
when acquiring a lock with "FOR UPDATE NOWAIT".
When "FOR UPDATE" is executed and interrupted by lock_timeout,
xid and PID are output in the logs, but in the case of "FOR UPDATE
NOWAIT",
no information is output, maki
On 9/13/24 06:04, Richard Guo wrote:
> On Mon, Sep 9, 2024 at 6:22 PM Tomas Vondra wrote:
>> I think we intentionally added incremental sort ... incrementally ;-)
>
> Haha, right.
>
>> I think one challenge with this case is that create_mergejoin_plan
>> creates these Sort plans explicitly -
On Tue, Sep 10, 2024 at 2:51 AM Masahiko Sawada wrote:
>
> On Mon, Sep 9, 2024 at 2:38 AM Shubham Khanna
> wrote:
> >
> > On Thu, Aug 29, 2024 at 11:46 AM Amit Kapila
> > wrote:
> > >
> > > On Thu, Aug 29, 2024 at 8:44 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Aug 28, 2024 at 1:
On 13.09.24 06:49, Hunaid Sohail wrote:
>
> $ bin/psql --port=5430 postgres
> psql (18devel)
> Type "help" for help.
>
> postgres=# \conninfo+
> You are connected to database "postgres" as user "hunaid" via socket
> in "/tmp" at port "5430".
> Co
On Mon, Sep 9, 2024 at 6:22 PM Tomas Vondra wrote:
> I have not thought about this particular case too much, but how likely
> is it that mergejoin will win for this plan in practice? If we consider
> a query that only needs a fraction of rows (say, thanks to LIMIT),
> aren't we likely to pick a ne
On Thu, Sep 12, 2024 at 4:03 AM Masahiko Sawada wrote:
>
> We have several reports that logical decoding uses memory much more
> than logical_decoding_work_mem[1][2][3]. For instance in one of the
> reports[1], even though users set logical_decoding_work_mem to
> '256MB', a walsender process was k
On Fri, Sep 13, 2024 at 3:02 PM Tatsuo Ishii wrote:
>
> > The patch looks fine but it doesn't add a test case where Storage is
> > Disk
>
> We can test the case by setting work_mem to the minimum size (64kB)
> and giving slightly larger "stop" parameter to generate_series.
>
WFM
> > or the case
On Thu, Sep 12, 2024 at 4:28 PM Nazir Bilal Yavuz wrote:
> >
> > Once this is done, I think we can mark this CF entry as RFC.
>
> Thanks for the changes. I applied all of them in respective patches.
Thanks a lot. PFA the patchset with
1. Improved comment related to PG_TEST_EXTRA in meson.build.
On Thu, Sep 12, 2024 at 3:04 PM shveta malik wrote:
>
> On Wed, Sep 11, 2024 at 2:40 AM John H wrote:
> >
> > Hi Shveta,
> >
> > On Sun, Sep 8, 2024 at 11:16 PM shveta malik wrote:
> >
> > >
> > > I was trying to have a look at the patch again, it doesn't apply on
> > > the head, needs rebase.
>
> The patch looks fine but it doesn't add a test case where Storage is
> Disk
We can test the case by setting work_mem to the minimum size (64kB)
and giving slightly larger "stop" parameter to generate_series.
> or the case when the last usage fit in memory but an earlier
> usage spilled to disk.
The patch looks fine but it doesn't add a test case where Storage is
Disk or the case when the last usage fit in memory but an earlier
usage spilled to disk. Do we want to cover those. This test would be
the only one where those code paths could be tested.
On Fri, Sep 13, 2024 at 11:41 AM Tatsuo I
On Fri, 13 Sept 2024 at 09:11, Tatsuo Ishii wrote:
> Thanks. Attached is the v4 patch. I am going push it if there's no
> objection.
>
Looks good to me. Thank you for your work.
--
Best regards,
Maxim Orlov.
On Tue, Sep 10, 2024 at 6:04 AM Thomas Munro wrote:
> On Tue, Sep 10, 2024 at 10:27 AM Thomas Munro
> wrote:
> > Mats, what do you think about
> > this? (I haven't tried to preserve the prefetching behaviour, which
> > probably didn't actually too work for you in v16 anyway at a guess,
> > I'm
Hello. This is my first patch to the project. The patch adds support for system columns in JOIN USING clause. The problemcan be demonstrated with this code: ```sqlCREATE TABLE t (id int);CREATE TABLE tt (id int); -- Works:SELECT * FROM t JOIN tt ON t.xmin = tt.xmin;-- Doesn't work:SELECT * FROM t
On Mon, Apr 1, 2024 at 3:15 AM Tom Lane wrote:
>
>
> > The format "%d-%s" is not ideal. I suggesst "%d (%s)".
>
> I didn't like that either, for two reasons: if we have a column name
> it ought to be the prominent label, but we might not have one if the
> TupleDesc came from some anonymous source
On Tue, Sep 10, 2024 at 12:28 AM Thomas Munro
wrote:
> On Tue, Sep 10, 2024 at 3:36 AM Michael Banck wrote:
> > I am a bit confused about the status of this thread. Robert mentioned
> > RC1, so I guess it pertains to v17 but I don't see it on the open item
> > wiki list?
>
> Yes, v17. Alight, I
On Fri, Sep 13, 2024 at 11:38 AM Amit Kapila wrote:
>
> > >
> > > So in brief, this solution is only for bidrectional setup? For
> > > non-bidirectional,
> > > feedback_slots is non-configurable and thus irrelevant.
> >
> > Right.
> >
>
> One possible idea to address the non-bidirectional case ra
Tender Wang 于2024年9月4日周三 11:48写道：
>
>
> Richard Guo 于2024年8月21日周三 15:11写道：
>
>> On Fri, Aug 16, 2024 at 4:14 PM Richard Guo
>> wrote:
>> > I had a self-review of this patchset and made some refactoring,
>> > especially to the function that creates the RelAggInfo structure for a
>> > given relat
On Fri, 26 Apr 2024 17:54:06 +0900
Yugo NAGATA wrote:
> On Wed, 24 Apr 2024 16:08:39 -0500
> Nathan Bossart wrote:
>
> > On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
> > > On the whole I find this proposed feature pretty unexciting
> > > and dubiously worthy of the implementation/m
On Thu, Sep 12, 2024 at 8:12 PM Amit Langote wrote:
>
> Hi Andreas,
>
> On Thu, Sep 12, 2024 at 7:08 PM Andreas Ulbrich
> wrote:
> >
> > Salvete!
> >
> >
> > Sorry for my out of the rules replay, but I'm not at home, and also I can't
> > verify and check your patch.
> >
> > But I think you have
56 matches
Mail list logo
