Upsert performance considerations (~1 mil/hour)

Hi, I have tried doing some research for quite a while on the performance implications of the built-in upsert (INSERT ... ON CONFLICT UPDATE...) when a lot of upserts are made. The scale is something like 1 million records/hour, that is split up in groups of around 300 records each. The table is

Re: Upsert performance considerations (~1 mil/hour)

Thanks for the response Jeff! On Wed, Sep 4, 2019 at 3:58 PM Jeff Janes wrote: > On Wed, Sep 4, 2019 at 1:30 PM Fredrik Blomqvist < > [email protected]> wrote: > >> Hi, >> >> I have tried doing some research for quite a while on the performance >> implications of the built-in upsert

Re: Upsert performance considerations (~1 mil/hour)

On Wed, Sep 4, 2019 at 1:30 PM Fredrik Blomqvist < [email protected]> wrote: > Hi, > > I have tried doing some research for quite a while on the performance > implications of the built-in upsert (INSERT ... ON CONFLICT UPDATE...) when > a lot of upserts are made. The scale is somethin

Re: Incorrect choice of Nested Loop for a skewed distribution

On Tue, Sep 03, 2019 at 09:47:42PM +0400, Oleg Kharin wrote: > Hi All, > > With PostgreSQL 10 and 11, the planner doesn't use the lists of most common > values to determine the selectivity of "=" for Nested Loop as it does for a > normal inner join in eqjoinsel_inner(). Incorrect choice of a neste