Dear Vignesh,
> One key point to consider is that the lock on transaction objects will
> be held for a longer duration when using streaming in parallel. This
> occurs because the parallel apply worker initiates the transaction as
> soon as streaming begins, maintaining the lock until the transacti
On Fri, May 24, 2024 at 03:59:08PM -0300, Fabrízio de Royes Mello wrote:
> Nice... LGTM!
I have noticed that this was still in the CF. After fixing a couple
of inconsistencies in the markups and the names, trimming down the
list of headers to avoid rot and adding a static in from of the const,
th
Le lun. 7 oct. 2024 à 02:41, Michael Paquier a écrit :
> On Mon, Oct 07, 2024 at 12:43:18AM +0300, Alena Rybakina wrote:
> > Maybe I'm not aware of the whole context of the thread and maybe my
> > questions will seem a bit stupid, but honestly
> > it's not entirely clear to me how this statistics
Hi David,
Thank you for your feedback.
On Fri, Oct 4, 2024 at 11:56 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> It seems to me a more useful definition for what this command should print
> out is basically the entire contents of:
>
> https://www.postgresql.org/docs/current/libpq-
Hi Andres Freund
Thank you for explanation
> I doubt that slowdown is caused by bgwriter not being active enough. I
suspect
> what you're seeing is one or more of:
> a) The overhead of doing full page writes (due to increasing the WAL
> volume). You could verify whether that's the case by tur
On Fri, Oct 04, 2024 at 08:16:00PM +0800, jian he wrote:
> about v5 0001
> select_with_parens:
> '(' select_no_parens ')'{ $$ = $2; }
> | '(' select_with_parens ')'{ $$ = $2; }
> ;
>
>
> toplevel | calls | query
Hi,
By default, currently streaming of in-progress transactions for
subscriptions is disabled. All transactions are fully decoded on the
publisher before being sent to the subscriber. This approach can lead
to increased latency and reduced performance, particularly under heavy
load. By default, we
On Thu, Aug 22, 2024 at 04:00:13PM +0530, Nishant Sharma wrote:
> I may be wrong, but just wanted to share my thoughts on the differences.
> So, it
> can be considered a different issue/mistake and can be handled separately in
> another email thread.
+else if (strcmp(def->defname, "column_
On Tue, Sep 10, 2024 at 05:11:13PM +1000, Peter Smith wrote:
> I have rebased the two remaining patches. See v12 attached.
I've looked over the patch set again, and applied 0002.
0001 could be more ambitious and more consistent, like:
- The GUC name coming from the table's record is only used for
On Tue, Feb 20, 2024 at 10:32:53PM +0100, Magnus Hagander wrote:
> In a way, that's yet another different type of values though -- it
> contains accumulated stats. So we really have 3 types -- "info" that's
> not really stats (username, etc), "current state" (query, wait events,
> state) and "accum
On Fri, Oct 04, 2024 at 10:02:11AM -0500, Nathan Bossart wrote:
> Could you explain why you feel the existing support functions are
> insufficient?
Because it is not possible to outsource the scan of pg_wal/summaries/
to a different role, no?
On HEAD, one would require a full access to the data f
On Mon, Oct 07, 2024 at 12:43:18AM +0300, Alena Rybakina wrote:
> Maybe I'm not aware of the whole context of the thread and maybe my
> questions will seem a bit stupid, but honestly
> it's not entirely clear to me how this statistics will help to adjust the
> number of parallel workers.
> We may h
On Sun, Oct 06, 2024 at 03:32:02PM +0200, Guillaume Lelarge wrote:
> I'm not sure I follow. That would mean that every time a query is executed,
> it always gets the same amount of workers. Which is not guaranteed to be
> true.
>
> I would agree, though, that parallelized_queries_launched is probab
On Mon, Oct 7, 2024 at 12:11 PM Tom Lane wrote:
> Hmm, I should think that if you break anything in tab-complete.in.c,
> the breakage would propagate to tab-complete.c without difficulty.
> Do you have an example of something that the preprocessor would mask?
Fair point, and nope. Thought withdr
Thomas Munro writes:
> On Sat, Jul 27, 2024 at 8:03 AM Tom Lane wrote:
>> I thought this version of the patch would be less subject to merge
>> conflicts than v1, but it didn't take long for somebody to break it.
>> Rebased v3 attached -- no nontrivial changes from v2.
> +1
Thanks for looking a
On 06.10.2024 02:22, David Rowley wrote:
To be honest, I don’t understand at all why we don’t count disabled nodes for
append here? As I understand it, this is due to the fact that the partitioned
table can also be scanned by an index. Besides mergeappend, in general it’s
difficult for me to g
On Sat, Jul 27, 2024 at 8:03 AM Tom Lane wrote:
> I wrote:
> > I modified the preprocessor to work like that, and I like the results
> > better than what I had.
>
> I thought this version of the patch would be less subject to merge
> conflicts than v1, but it didn't take long for somebody to break
Hi!
Finally found some time to work on this. Tests added on v5 patch
(attached).
Maybe I'm not aware of the whole context of the thread and maybe my
questions will seem a bit stupid, but honestly
it's not entirely clear to me how this statistics will help to adjust
the number of parallel worke
Soumyadeep Chakraborty writes:
> Attached is a simple patch to directly use heap scan routines in
> vac_update_datfrozenxid(), avoiding the multilayer overhead from the
> sysscan infrastructure.
I would think the overhead of that is minuscule. If it isn't,
we should try to make it so, not random
Hi hackers,
Attached is a simple patch to directly use heap scan routines in
vac_update_datfrozenxid(), avoiding the multilayer overhead from the
sysscan infrastructure. The speedup can be noticeable in databases
containing a large number of relations (perhaps due to heavy partition
table usage).
Hello,
Le jeu. 5 sept. 2024 à 08:19, Guillaume Lelarge a
écrit :
> Le jeu. 5 sept. 2024 à 07:36, Bertrand Drouvot <
> bertranddrouvot...@gmail.com> a écrit :
>
>> Hi,
>>
>> On Wed, Sep 04, 2024 at 04:37:19PM +0200, Guillaume Lelarge wrote:
>> > Hi,
>> >
>> > Le mer. 4 sept. 2024 à 16:18, Bertran
Joe Conway writes:
> I think it would be nice to include a sha256 hash (or something similar)
> of the libraries as well, so that they can be checked against known good
> values.
That seems well outside the charter of this patch. Also, how would
we even get that information? A typical applica
On 10/6/24 11:36, Dmitry Dolgov wrote:
Hi,
Based on the feedback in [1], here is my attempt at implementing system
views for versions reporting. It adds pg_system_versions for showing
things like core version, compiler, LLVM, etc, and pg_system_libraries
for showing linked shared objects. I thin
Hi,
Based on the feedback in [1], here is my attempt at implementing system
views for versions reporting. It adds pg_system_versions for showing
things like core version, compiler, LLVM, etc, and pg_system_libraries
for showing linked shared objects. I think everyone has ageed that the
first was a
Hi Michael,
Le jeu. 3 oct. 2024 à 09:15, Michael Paquier a écrit :
> On Thu, Aug 29, 2024 at 10:08:23PM +0200, Guillaume Lelarge wrote:
> > This patch was a bit discussed on [1], and with more details on [2]. It's
> > based on another patch sent in 2022 (see [3]). It introduces seven new
> > col
On 2024-10-04 Fr 12:19 PM, Joel Jacobson wrote:
On Sun, Jul 2, 2023, at 07:45, Noah Misch wrote:
On Sat, May 20, 2023 at 09:16:30AM +0200, Joel Jacobson wrote:
On Fri, May 19, 2023, at 18:06, Daniel Verite wrote:
COPY FROM file CSV somewhat differs as your example shows,
but it still mishandl
On Sun, Oct 06, 2024 at 11:42:53AM +0200, Hannu Krosing wrote:
> On Fri, Oct 4, 2024 at 4:48 PM Nathan Bossart
> wrote:
>> Since BLCKSZ can be as low as 1024, I think 512 would be a good choice.
>
> Where did you get the minimal value of 1024 from ?
https://www.postgresql.org/docs/deve
On Fri, Oct 4, 2024 at 4:34 PM Robert Haas wrote:
> On Mon, Sep 23, 2024 at 7:11 AM Alexander Korotkov
> wrote:
> > Makes sense. Please, check the attached patch freeing the consts list
> > while returning NULL from match_orclause_to_indexcol().
>
> Some review comments:
>
> I agree with the co
On Tue, Oct 1, 2024 at 7:07 PM Takeshi Ideriha wrote:
>
> >We forgot to set/unset the flag in functions
> >systable_beginscan_ordered and systable_endscan_ordered. BTW,
>
> Thank you for the clarification.
>
> >shouldn't this occur even without prepare transaction? If so, we need
> >to backpatch t
On Fri, Oct 4, 2024 at 4:48 PM Nathan Bossart wrote:
>
..
> Since BLCKSZ can be as low as 1024, I think 512 would be a good choice.
>
Where did you get the minimal value of 1024 from ?
I vaguely remember someone testing with 256 at some point in the past
---
Hannu
On Thu, Oct 03, 2024 at 08:12:28PM -0400, Tom Lane wrote:
> OK, if there's no objections let's push both remaining patches
> to HEAD only.
Done as of f22e84df1dea and 430ce189fc45.
--
Michael
signature.asc
Description: PGP signature
31 matches
Mail list logo
