Re: More efficient RI checks - take 2

2020-09-26 Thread Justin Pryzby
On Fri, Jun 05, 2020 at 05:16:43PM +0200, Antonin Houska wrote: > Antonin Houska wrote: > > > In general, the checks are significantly faster if there are many rows to > > process, and a bit slower when we only need to check a single row. > > Attached is a new version that uses the existing

Re: Avoid suspects casts VARHDRSZ (c.h)

2020-09-26 Thread Tom Lane
Ranier Vilela writes: > In all the static analysis tools I’ve used, there are literally *hundreds* > of alerts about a one suspect cast: > 64 bits sizet_t -> 32 bits int -> 64 bits size_t > -#define VARHDRSZ ((int32) sizeof(int32)) > +#define VARHDRSZ (sizeof(int32)) Given that the compiler can

Re: Get rid of runtime handling of AlternativeSubPlan?

2020-09-26 Thread Tom Lane
Thanks for reviewing! David Rowley writes: > 1. I think we should be moving away from using linitial() and second() > when we know there are two items in the list. Using list_nth() has > less overhead. Uh, really? And if it's true, why would we change all the call sites rather than improving

Re: 回复:how to create index concurrently on partitioned table

2020-09-26 Thread Justin Pryzby
On Thu, Sep 24, 2020 at 05:11:03PM +0900, Michael Paquier wrote: > start. So, the goal of the patch, as I would define it, is to give a > way to CLUSTER to work on a partitioned table using a given > partitioned index. Hence, we would perform CLUSTER automatically from > the top-most parent for

enable_incremental_sort changes query behavior

2020-09-26 Thread Jaime Casanova
Hi, With sqlsmith I found a query that gives this error: ERROR: ORDER/GROUP BY expression not found in targetlist I noted the query (sql query below, sorry it uses custom tables i couldn't replicate with regression tables) because it doesn't include an ORDER/GROUP BY clause. --- 0 select

Re: Libpq support to connect to standby server as priority

2020-09-26 Thread Tom Lane
I wrote: > BTW, I think it would be worth splitting this into separate server-side > and libpq patches. It looked to me like the server side is pretty > nearly committable, modulo bikeshedding about the new GUC name. Actually ... I looked that over again and got a bit more queasy about all the

Re: Parallel INSERT (INTO ... SELECT ...)

2020-09-26 Thread vignesh C
On Wed, Sep 23, 2020 at 2:21 PM Greg Nancarrow wrote: > > > - When INSERTs are made parallel, currently the reported row-count in > > the "INSERT 0 " status only reflects the rows that the > > leader has processed (not the workers) - so it is obviously less than > > the actual number of rows

Re: Get rid of runtime handling of AlternativeSubPlan?

2020-09-26 Thread David Rowley
On Tue, 1 Sep 2020 at 05:22, Tom Lane wrote: > > I wrote: > > One inefficiency I see that we could probably get rid of is > > where make_subplan() is doing > > /* Now we can check if it'll fit in hash_mem */ > > /* XXX can we check this at the Path stage? */ > > I went

Avoid suspects casts VARHDRSZ (c.h)

2020-09-26 Thread Ranier Vilela
Hi, In all the static analysis tools I’ve used, there are literally *hundreds* of alerts about a one suspect cast: 64 bits sizet_t -> 32 bits int -> 64 bits size_t -#define VARHDRSZ ((int32) sizeof(int32)) +#define VARHDRSZ (sizeof(int32)) Is there any special reason for not simplifying this

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

2020-09-26 Thread Amit Kapila
On Wed, Sep 23, 2020 at 1:09 PM Keisuke Kuroda wrote: > > Hi hackers, > > I found a problem in logical replication. > It seems to have the same cause as the following problem. > > Creating many tables gets logical replication stuck > >

Re: Asynchronous Append on postgres_fdw nodes.

2020-09-26 Thread Etsuro Fujita
On Thu, Aug 20, 2020 at 4:36 PM Kyotaro Horiguchi wrote: > This is rebased version. Thanks for the rebased version! > Come to think of "complex", ExecAsync stuff in this patch might be > too-much for a short-term solution until executor overhaul, if it > comes shortly. (the patch of mine here

Re: New statistics for tuning WAL buffer size

2020-09-26 Thread Amit Kapila
On Fri, Sep 25, 2020 at 11:06 PM Fujii Masao wrote: > > On 2020/09/25 12:06, Masahiro Ikeda wrote: > > On 2020-09-18 11:11, Kyotaro Horiguchi wrote: > >> At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda > >> wrote in > >>> Thanks. I confirmed that it causes HOT pruning or killing of > >>> dead

Re: Dynamic gathering the values for seq_page_cost/xxx_cost

2020-09-26 Thread Andy Fan
On Sat, Sep 26, 2020 at 1:51 PM Julien Rouhaud wrote: > On Sat, Sep 26, 2020 at 8:17 AM Andy Fan wrote: > > > > As for the testing with cache considered, I found how to estimate cache > hit > > ratio is hard or how to control a hit ratio to test is hard. Recently I > am thinking > > a method

Re: Parallel INSERT (INTO ... SELECT ...)

2020-09-26 Thread Amit Kapila
On Fri, Sep 25, 2020 at 9:11 AM Greg Nancarrow wrote: > > > > What if this > > > ends up being invoked from inside C code? > > > > > > > I think it shouldn't be a problem unless one is trying to do something > > like insert into foreign key table. So, probably we can have an Assert > > to catch

Re: Logical replication from PG v13 and below to PG v14 (devel version) is not working.

2020-09-26 Thread Amit Kapila
On Fri, Sep 25, 2020 at 1:53 PM Dilip Kumar wrote: > > On Fri, Sep 25, 2020 at 8:12 AM Amit Kapila wrote: > > > > > > No that won't happen because we send this option to the server > > (publisher in this case) only when version is >=14 and user has > > specified this option. See the below check

Re: [Patch] Optimize dropping of relation buffers using dlist

2020-09-26 Thread Amit Kapila
On Fri, Sep 25, 2020 at 1:49 PM k.jami...@fujitsu.com wrote: > > Hi. > > > I'll send performance measurement results in the next email. Thanks a lot > > for > > the reviews! > > Below are the performance measurement results. > I was only able to use low-spec machine: > CPU 4v, Memory 8GB, RHEL,

Re: [Patch] Optimize dropping of relation buffers using dlist

2020-09-26 Thread Amit Kapila
On Fri, Sep 25, 2020 at 2:25 PM tsunakawa.ta...@fujitsu.com wrote: > > From: Amit Kapila > > No, during recovery also we need to be careful. We need to ensure that > > we use cached value during recovery and cached value is always > > up-to-date. We can't rely on lseek and I have provided some