On Mon, Dec 24, 2012 at 06:37:11PM +, Richard Neill wrote:
> [...]
> So... problem solved for me: I just have to reindex every few hours.
> BUT, this suggests a few remaining things:
> [...]
> 2. Is there any way to force the planner to use (or ignore) a
> specific index, for testing purposes,
Emmanuel, I really appreciate you getting back on this old old topic.
Wish you a very very happy Christmas and happy new year.
I'm
kinda disappointed to see that since 2008 pgsql has not evolved to support
native
partitioning. Partitioning with Triggers is so slow.
Looks like pgsql lost some mo
Dear All,
I think periodic reindex may be the solution. Even after reducing the
autovacuum fraction to 0.05, the index still seems to bloat.
After another couple of days runtime, the index is using 11MB, and
I get a query that takes 2.448ms. Then I reindex (takes about 3 sec),
and the index f
I've just found this:
From:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01221.php
"initial tests to insert 140k rows are as follows:
- direct inserts in a child table: 2 seconds
- pgplsql trigger (IF ... ELSE IF ... blocks) : 14.5 seconds.
- C trigger: 4 seconds (actually the overh
On Dec 24, 2012, at 9:07 PM, Charles Gomes wrote:
> By the way, I've just re-wrote the code to target the partitions individually
> and I've got almost 4 times improvement.
> Shouldn't it be faster to process the trigger, I would understand if there
> was no CPU left, but there is lots of cpu
By the way, I've just re-wrote the code to target the partitions individually
and I've got almost 4 times improvement.
Shouldn't it be faster to process the trigger, I would understand if there was
no CPU left, but there is lots of cpu to chew.
It seems that there will be no other way to speedup
> Date: Sun, 23 Dec 2012 14:55:16 -0800
> Subject: Re: [PERFORM] Performance on Bulk Insert to Partitioned Table
> From: jeff.ja...@gmail.com
> To: charle...@outlook.com
> CC: ondrej.iva...@gmail.com; pgsql-performance@postgresql.org
>
> On Thursday, December
