On Tue, Jul 6, 2021 at 1:51 PM Amit Kapila wrote:
> > Okay, I'll push it early next week (by Tuesday) unless there are more
> > comments or suggestions. Thanks!
> >
>
> Pushed!
Thanks, Amit. I'm posting the 0002 patch which removes extra ereport
calls using local variables. Please review it.
On Tue, Jul 6, 2021 at 1:38 PM Michael Paquier wrote:
>
> On Tue, Jul 06, 2021 at 12:42:21PM +0530, Bharath Rupireddy wrote:
> > I'm sorry to say that I didn't get what was said above. We reset the
> > latch after we come out of WaitLatch but not before going to wait. And
> > the reason to have
On Tue, Jul 6, 2021 at 10:58 AM Masahiko Sawada
wrote:
> > Also, I'd like to suggest thinking twice about the view name (and
> function used in view DDL) - "pg_stat_logical_replication_error" contains
> very common "logical replication" words, but the view contains errors
> related to
Hi all,
When I read the source code file src/backend/access/transam/xloginsert.c, I get
something confused me.
In the function XLogSaveBufferForHint, the flags are always REGBUF_FORCE_IMAGE
which means it is always need backups.
Is it right? Why do not check the full_page_writes?
--
Zhang
On 7/5/21 11:46 PM, Bharath Rupireddy wrote:
> On Tue, Jul 6, 2021 at 12:43 AM Tom Lane wrote:
>> Noah Misch writes:
>>> On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote:
However, I think we should also give serious consideration to
"debug_clobber_cache" or
On Sun, 4 Jul 2021 at 02:08, Andy Fan wrote:
> I'd start to work on UniqueKey again, it would be great that we can target it
> to PG 15. The attached patch is just for the notnull_attrs. Since we can't
> say
> a column is nullable or not without saying in which resultset, so I think
>
On Tue, Jul 6, 2021 at 12:30 PM Masahiko Sawada wrote:
>
> On Mon, Jul 5, 2021 at 6:46 PM Amit Kapila wrote:
> >
> > On Thu, Jul 1, 2021 at 6:31 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Jul 1, 2021 at 12:56 PM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Don't we want to clear
On Fri, Jun 18, 2021 at 12:50 AM Robert Haas wrote:
>
> On Thu, Jun 17, 2021 at 2:48 PM Andres Freund wrote:
> > Or do you mean that looking at the filesystem at all is bypassing shared
> > buffers?
>
> This is what I mean. I think we will end up in a better spot if we can
> avoid doing that
On 5/7/21 23:15, Zhihong Yu wrote:
On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
+ * Can't imagine situation when join relation already
exists. But in
+ * the 'partition_join' regression test it happens.
+ * It may be
On Mon, 5 Jul 2021 at 20:00, David Rowley wrote:
> I don't really like the fact that I had to add the doHalfRound field
> to get the same rounding behaviour as the original functions. I'm
> wondering if it would just be too clever just to track how many bits
> we've shifted right by in
On Tue, Jul 6, 2021 at 11:28 AM Masahiko Sawada wrote:
>
> On Mon, Jul 5, 2021 at 7:33 PM Alexey Lesovsky wrote:
> >
> > Hi,
> > Have a few notes about pg_stat_logical_replication_error from the DBA point
> > of view (which will use this view in the future).
>
> Thank you for the comments!
>
>
Thanks for the comment.
At Tue, 6 Jul 2021 11:17:47 +0900, Michael Paquier wrote
in
> On Thu, Jul 01, 2021 at 06:45:25PM +0900, Kyotaro Horiguchi wrote:
> > Separating "CREATE TABLE AS EXECUTE" from ExecuteStmt would be cleaner
> > but I avoided to change the syntax tree. Instead the attched
On Sun, Mar 14, 2021 at 06:00:00PM +0300, Alexander Lakhin wrote:
> I believe that the patch attached to [1] should fix this issue. The
> patch still applies to master and makes the demotest (attached to [2])
> pass. Also I've prepared a trivial patch that makes pgwin32_open() use
> the original
At Fri, 2 Jul 2021 12:53:02 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Hackers,
>
> I revised my patch.
Thanks for the new version.
> > However, I perfectly agree that it's very difficult for users to find a
> > problem from the message.
> > I will try to add information to it in
On Fri, Jul 2, 2021 at 12:36 PM Amit Kapila wrote:
>
> On Fri, Jul 2, 2021 at 8:35 AM Alvaro Herrera wrote:
> >
> > > The latest patch sent by Bharath looks good to me. Would you like to
> > > commit it or shall I take care of it?
> >
> > Please, go ahead.
> >
>
> Okay, I'll push it early next
On Tue, Jul 6, 2021 at 11:36 AM Dipesh Pandit wrote:
>
> Hi,
>
> We have addressed the O(n^2) problem which involves directory scan for
> archiving individual WAL files by maintaining a WAL counter to identify
> the next WAL file in a sequence.
>
> WAL archiver scans the status directory to
On Tue, Jul 06, 2021 at 12:42:21PM +0530, Bharath Rupireddy wrote:
> I'm sorry to say that I didn't get what was said above. We reset the
> latch after we come out of WaitLatch but not before going to wait. And
> the reason to have WL_LATCH_SET, is to exit the wait loop if MyLatch
> is set for
On Tue, Jul 06, 2021 at 04:58:03PM +0900, Michael Paquier wrote:
> I have been chewing on this comment and it took me some time to
> understand what you meant here. It is true that the ecpglib part, aka
> all the routines you are quoting above, don't rely at all on the
> connection names.
On Fri, Jul 02, 2021 at 12:53:02PM +, kuroda.hay...@fujitsu.com wrote:
> I added such a message and some tests, but I began to think this is strange.
> Now I'm wondering why the connection is checked in some DESCRIPTOR-related
> statements? In my understanding connection name is not used in
>
Hello Ishii-san,
On Fri, 02 Jul 2021 09:25:03 +0900 (JST)
Tatsuo Ishii wrote:
> I have found an interesting result from patched pgbench (I have set
> the isolation level to REPEATABLE READ):
>
> $ pgbench -p 11000 -c 10 -T 30 --max-tries=0 test
> pgbench (15devel, server 13.3)
> starting
On Mon, 5 Jul 2021 at 18:38, Ronan Dunklau wrote:
> I think the overhead occurs because in the ExecAgg case, we use the
> tuplesort_*_datum API as an optimization when we have a single column as an
> input, which the ExecSort code doesn't. Maybe it would be worth it to try to
> use that API in
Fabien COELHO писал 2021-07-06 09:13:
Hello Yura,
I believe most "range" values are small, much smaller than UINT32_MAX.
In this case, according to [1] fastest method is Lemire's one (I'd
take
original version from [2]) [...]
Yep.
I share your point that the range is more often 32 bits.
On Tue, Jul 6, 2021 at 6:15 AM Michael Paquier wrote:
> On Mon, Jul 05, 2021 at 09:42:29PM +0530, Bharath Rupireddy wrote:
> > I agree. I'm attaching the patch that replaces pg_usleep with
> > WaitLatch for {pre, post}_auth_delay. I'm also attaching Michael's
> > latest patch
On Mon, Jul 5, 2021 at 6:46 PM Amit Kapila wrote:
>
> On Thu, Jul 1, 2021 at 6:31 PM Masahiko Sawada wrote:
> >
> > On Thu, Jul 1, 2021 at 12:56 PM Amit Kapila wrote:
> > >
> > >
> > > Don't we want to clear stats at drop subscription as well? We do drop
> > > database stats in dropdb via
> If you make a separate thread and CF entry, please CC me and add me as
> a reviewer on the CF entry.
Ok, I started a new thread and added it to the next CF: https://
commitfest.postgresql.org/34/3237/
--
Ronan Dunklau
Hi,
I'm interested in this patch and I also run the same test with Ikeda-san's
fxact_update.pgbench.
In my environment (poor spec VM), the result is following.
* foreign_twophase_commit = disabled
363tps
* foreign_twophase_commit = required (It is necessary to set -R ${RATE} as
Ikeda-san
Hello,
While testing the patch "Add proper planner support for ORDER BY / DISTINCT
aggregates" [0] I discovered the performance penalty from adding a sort node
essentially came from not using the single-datum tuplesort optimization in
ExecSort (contrary to the sorting done in ExecAgg).
I
Hello Yura,
I believe most "range" values are small, much smaller than UINT32_MAX.
In this case, according to [1] fastest method is Lemire's one (I'd take
original version from [2]) [...]
Yep.
I share your point that the range is more often 32 bits.
However, I'm not enthousiastic at
Hi,
We have addressed the O(n^2) problem which involves directory scan for
archiving individual WAL files by maintaining a WAL counter to identify
the next WAL file in a sequence.
WAL archiver scans the status directory to identify the next WAL file
which needs to be archived. This directory
101 - 129 of 129 matches
Mail list logo
