From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: When to use PARTITION BY HASH? |
Date: | 2020-06-07 01:58:08 |
Message-ID: | fa380e6c-301b-3db4-4ce3-75f7af660637@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
On 6/5/20 8:51 AM, Jeff Janes wrote:
> On Fri, Jun 5, 2020 at 6:12 AM Oleksandr Shulgin
> <oleksandr(dot)shulgin(at)zalando(dot)de <mailto:oleksandr(dot)shulgin(at)zalando(dot)de>> wrote:
[snip]
>
> For a bulk load you'd likely want to go with an empty partition w/o
> indexes and build them later, after loading the tuples.
>
>
> That only works if the bulk load is starting from zero. If you are adding
> a million rows to something that already has 100 million, you would
> probably spend more time rebuilding the indexes than you saved by dropping
> them.
It's too bad that Postgres doesn't have "deferred index updates" during bulk
(but still transactional) loads, where the index nodes are updated /en
masse/ every "commit count" number of rows. That's *really useful* in this
situation, but I've only seen it in one legacy RDBMS.
--
Angular momentum makes the world go 'round.
From | Date | Subject | |
---|---|---|---|
Next Message | Wenjun Che | 2020-06-07 03:24:15 | Question on full vacuum clearing waste space |
Previous Message | Tim Cross | 2020-06-07 00:32:39 | Re: Should I enforce ssl/local socket use? |
From | Date | Subject | |
---|---|---|---|
Next Message | MichaelDBA | 2020-06-07 11:41:28 | Re: When to use PARTITION BY HASH? |
Previous Message | Michel Pelletier | 2020-06-06 16:13:25 | Re: When to use PARTITION BY HASH? |