Re: Delay locking partitions during query execution - Mailing list pgsql-hackers

From David Rowley
Subject Re: Delay locking partitions during query execution
Date
Msg-id CAKJS1f9SHTxYb0n5YtOE8H-gU3H3ZWRajNHppN+trmvgZxNRwg@mail.gmail.com
Whole thread Raw
In response to Re: Delay locking partitions during query execution  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Sat, 5 Jan 2019 at 03:12, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> >>
> >>     partitions    0      100     1000    10000
> >>     --------------------------------------------
> >>     master       19     1590     2090      128
> >>     patched      18     1780     6820     1130
> >>
> >> So, that's nice. I wonder why the throughput drops so fast between 1k
> >> and 10k partitions, but I'll look into that later.
> >
> > Those look strange. Why is it so slow with the non-partitioned case?
> > I'd have expected that to be the fastest result.
> >
>
> Because there are 1M rows in the table, and it's doing a seqscan.

Of course. My test did the same, but I didn't consider that because I
had so few rows per partition.  Likely just adding an index would have
it make more sense.


-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Next
From: Mitar
Date:
Subject: Re: Feature: triggers on materialized views