Am 17.07.22 um 05:37 schrieb Tom Lane:
Actually ... is there a reason to bother with an intarray version
at all, rather than going straight for an in-core anyarray function?
It's not obvious to me that an int4-only version would have
major performance advantages.
regards
Am 17.07.22 um 08:00 schrieb Thomas Munro:
I went to see what Professor Lemire would have to say about all this,
expecting to find a SIMD rabbit hole to fall down for some Sunday
evening reading, but the main thing that jumped out was this article
about the modulo operation required by textbook
Am 17.07.22 um 05:32 schrieb David G. Johnston:
+SELECT sample('{1,2,3,4,5,6,7,8,9,10,11,12}', 6) !=
sample('{1,2,3,4,5,6,7,8,9,10,11,12}', 6);
+ ?column?
+--
+ t
+(1 row)
+
While small, there is a non-zero chance for both samples to be equal. This
test should probably just go, I don
On Sun, 17 Jul 2022 at 07:19, Michael Paquier wrote:
>
> On Fri, Jul 15, 2022 at 06:21:22PM +0100, Simon Riggs wrote:
> > That's fixed it on the CFbot. Over to you, Michael. Thanks.
>
> Sure. I have looked over that, and this looks fine overall. I have
> made two changes though.
>
> if (
On Fri, Jul 15, 2022 at 3:32 PM shiy.f...@fujitsu.com
wrote:
>
> On Mon, Jul 11, 2022 9:54 PM Masahiko Sawada wrote:
> >
> > I've attached an updated patch, please review it.
> >
>
> Thanks for your patch. Here are some comments for the REL14-v1 patch.
>
> 1.
> + Sizesz
Thanks for updating the patch.
This failed to build on windows.
http://cfbot.cputube.org/pavel-stehule.html
Some more comments inline.
On Sun, Jul 17, 2022 at 08:20:47AM +0200, Pavel Stehule wrote:
> The attached patch implements the --filter option for pg_dumpall and for
> pg_restore too.
> di
On Fri, Jul 15, 2022 at 09:37:14PM -0500, Justin Pryzby wrote:
> I'm not suggesting to give the community regulars special treatment, but you
> could reasonably assume that when they added themselves and then "didn't
> remove
> themself", it was on purpose and not by omission. I think most of tho
В Вт, 12/07/2022 в 22:41 -0700, Andres Freund пишет:
> Hi,
>
> On 2022-07-12 10:42:07 -0700, Andres Freund wrote:
> > On 2022-07-12 17:01:18 +1200, David Rowley wrote:
> > > There is at least one. It might be major; to reduce the AllocSet chunk
> > > header from 16 bytes down to 8 bytes I had to g
Am 17.07.22 um 08:00 schrieb Thomas Munro:
Actually ... is there a reason to bother with an intarray version
at all, rather than going straight for an in-core anyarray function?
It's not obvious to me that an int4-only version would have
major performance advantages.
Yeah, that seems like a goo
Hi hackers!
Aleksander, I've carefully gone over discussion and still have some
questions to ask -
1) Is there any means of measuring overhead of dictionaries over vanilla
implementation? IMO it is a must because
JSON is a widely used functionality. Also, as it was mentioned before, to
check the
Hi everyone!
Here's the attached patch submission to optimize pg_rewind performance when
many WAL files are retained on server. This patch avoids replaying (copying
over) older WAL segment files that fall before the point of divergence between
the source and target servers.
Thanks,
Justin
Hi everyone!
I've also attached the pg_rewind optimization patch file for Postgres version
14.4. The previous patch file targets version Postgres version 15 Beta 1/2.
Thanks,
Justin
From: Justin Kwan
Sent: July 15, 2022 6:13 PM
To: vignesh ravichandran
Cc: pgsq
Justin Kwan writes:
> I've also attached the pg_rewind optimization patch file for Postgres version
> 14.4. The previous patch file targets version Postgres version 15 Beta 1/2.
It's very unlikely that we would consider committing such changes into
released branches. In fact, it's too late even
Andres Freund writes:
> On 2022-03-24 16:13:31 +0100, Peter Eisentraut wrote:
>> The easiest solution would be to change worker_spi's Makefile to use
>> MODULE_big.
> If it were just worker_spi that might be tenable, but there's other extension
> modules - even if they don't fail to fail right no
I wrote:
> I also notice that setrefs.c can elide Append and MergeAppend nodes
> too in some cases, but AFAICS costing of those node types doesn't
> take that into account.
I took a closer look at this point and realized that in fact,
create_append_path and create_merge_append_path do attempt to a
Rebased yet again...
On Mon, Jul 4, 2022 at 1:17 PM Kenaniah Cerny wrote:
> Hi Antonin,
>
> First of all, thank you so much for taking the time to review my patch.
> I'll answer your questions in reverse order:
>
> The "unsafe_tests" directory is where the pre-existing role tests were
> located.
Hi,
Thanks for the quick review.
On 2022-07-17 14:54:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Is there any reason an extension module would need to directly link against
> > pgport/pgcommon? I don't think so, right?
>
> Shouldn't --- we want it to use the backend's own copy. (Hmm
Andres Freund writes:
> That's also the reason -fvisibility=hidden isn't added to libpq and the ecpg
> libs - their symbol visility is done via exports.txt. Depending on the
> platform that'd not work if symbols were already hidden via
> -fvisibility=hidden (unless explicitly exported via PGDLLEXP
On Wed, Jul 13, 2022 at 12:33 AM Michel Pelletier
wrote:
> On Thu, 30 Jun 2022 at 18:09, Michael Paquier wrote:
>
>> On Fri, Jul 01, 2022 at 10:06:49AM +0900, Michael Paquier wrote:
>> > And the conclusion back then is that one can already achieve this by
>> > using PGOPTIONS:
>> > PGOPTIONS='-c
Robert Haas writes:
> On Mon, May 16, 2022 at 1:33 PM Tom Lane wrote:
>> 0002 tightens deparse.c's rules to only consider an OID alias constant
>> as shippable if the object it refers to is shippable. This seems
>> obvious in hindsight; I wonder how come we've not realized it before?
>> However,
On Mon, Jul 18, 2022 at 4:15 AM Martin Kalcher
wrote:
> Am 17.07.22 um 08:00 schrieb Thomas Munro:
> >> Actually ... is there a reason to bother with an intarray version
> >> at all, rather than going straight for an in-core anyarray function?
> >> It's not obvious to me that an int4-only version
Martin Kalcher writes:
> Am 17.07.22 um 08:00 schrieb Thomas Munro:
>>> Actually ... is there a reason to bother with an intarray version
>>> at all, rather than going straight for an in-core anyarray function?
> I played around with the idea of an anyarray shuffle(). The hard part
> was to deal
Thomas Munro writes:
> Seems OK for a worst case. It must still be a lot faster than doing
> it in SQL. Now I wonder what the exact requirements would be to
> dispatch to a faster version that would handle int4.
I find it impossible to believe that it's worth micro-optimizing
shuffle() to that
Am 18.07.22 um 00:46 schrieb Tom Lane:
This does not look particularly idiomatic, or even type-safe. What you
should have done was use deconstruct_array to get an array of Datums and
isnull flags, then shuffled those, then used construct_array to build the
output.
(Or, perhaps, use construct_m
On Sat Jul 16, 2022 at 11:23 PM EDT, David G. Johnston wrote:
> Thanks for the review. I generally like everything you said but it made me
> realize that I still didn't really understand the intent behind the
> formula. I spent way too much time working that out for myself, then
> turned what I f
Am 18.07.22 um 00:37 schrieb Thomas Munro:
Seems OK for a worst case. It must still be a lot faster than doing
it in SQL. Now I wonder what the exact requirements would be to
dispatch to a faster version that would handle int4. I haven't
studied this in detail but perhaps to dispatch to a fast
Martin Kalcher writes:
> Am 18.07.22 um 00:46 schrieb Tom Lane:
>> This does not look particularly idiomatic, or even type-safe. What you
>> should have done was use deconstruct_array to get an array of Datums and
>> isnull flags, then shuffled those, then used construct_array to build the
>> out
I've run into an existing behavior where xmax(), and various other system
tables, return an error when included in the RETURNING list on a
partitioned table.
ERROR: cannot retrieve a system column in this context
`
This issue got a fair airing back in 2020:
AW: posgres 12 bug (partitioned table)
Hi,
On 2022-07-18 09:46:44 +0700, John Naylor wrote:
> I've made a small step in this direction.
Thanks for working on this!
> 0001 is just boilerplate, same as v1
If we were to go for this, I wonder if we should backpatch the cast containing
version of GESTRUCT for less pain backpatching bugf
On Fri, Apr 8, 2022 at 7:56 PM Dave Page wrote:
> Windows 8 was a pretty unpopular release, so I would expect shifting to
> 10/2016+ for PG 16 would be unlikely to be a major problem.
Thanks to Michael for making that happen. That removes the main thing
I didn't know how to deal with in this pa
On Fri, Jul 15, 2022 10:39 PM Masahiko Sawada wrote:
>
> This patch should have the fix for the issue that Shi yu reported. Shi
> yu, could you please test it again with this patch?
>
Thanks for updating the patch!
I have tested and confirmed that the problem I found has been fixed.
Regards,
S
Thomas Munro writes:
> With my garbage collector hat on, I see that all systems we target
> have fdatasync(), except:
> 1. Windows, but this patch supplies src/port/fdatasync.c.
> 2. DragonflyBSD before 6.1. We have 6.0 in the build farm.
> 3. Ancient macOS. Current releases have it, though
On Fri, Jul 15, 2022 at 8:09 PM Masahiko Sawada wrote:
>
> This patch should have the fix for the issue that Shi yu reported. Shi
> yu, could you please test it again with this patch?
>
Can you explain the cause of the failure and your fix for the same?
--
With Regards,
Amit Kapila.
On Mon, Jul 18, 2022 at 3:43 PM Tom Lane wrote:
> Thomas Munro writes:
> > With my garbage collector hat on, I see that all systems we target
> > have fdatasync(), except:
>
> > 1. Windows, but this patch supplies src/port/fdatasync.c.
> > 2. DragonflyBSD before 6.1. We have 6.0 in the build f
Thomas Munro writes:
> ... I was just noting an upcoming
> opportunity to remove the configure/meson probes for fdatasync, which
> made me feel better about the slightly kludgy way this patch is
> defining HAVE_FDATASYNC explicitly on Windows.
Hm. There is certainly not any harm in the meson inf
On Sat, Jul 16, 2022 at 10:29 AM Dilip Kumar wrote:
>
> I think giving two options would be really confusing from the
> usability perspective. I think what we should be doing here is to
> keep these three names 'none', 'any' and 'local' as reserved names for
> the origin name so that those are no
On Mon, Jul 18, 2022 at 3:16 AM Tom Lane wrote:
> I wrote:
> > I also notice that setrefs.c can elide Append and MergeAppend nodes
> > too in some cases, but AFAICS costing of those node types doesn't
> > take that into account.
>
> I took a closer look at this point and realized that in fact,
>
On Tue, Jul 12, 2022 at 7:07 PM Önder Kalacı wrote:
>
> Hi hackers,
>
>
> It is often not feasible to use `REPLICA IDENTITY FULL` on the publication,
> because it leads to full table scan
>
> per tuple change on the subscription. This makes `REPLICA IDENTITY FULL`
> impracticable -- probably oth
38 matches
Mail list logo
