From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gin fast insert performance |
Date: | 2009-01-27 17:50:51 |
Message-ID: | 1233078651.1243.16.camel@dell.linuxdev.us.dell.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2009-01-27 at 20:36 +0300, Teodor Sigaev wrote:
> You didn't provide distributions of array's element, number of unique element
> and so on. And I make simple test script, which generates data rather close to
> typical tsearch installation (see tst.sql).
The arrays I was inserting were actually all identical. In the case of a
1000-element array inserted 10000 times, it was just ARRAY[1, 2, ...,
1000].
My test case must have been much to simple, but I expected that it would
still benefit from fast insert.
> "but increased work_mem clearly *may* defer a lot of the work to VACUUM."
> Because in real world it's impossible to predict when clearing of pending list
> will be started. And autovacuum usually will fire the clearing earlier than
> pending list reaches the limit.
Yes, that is the expected result and part of the design. It was just an
observation, not a criticism.
I will try with a better test case.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-27 17:52:41 | Re: 8.4 release planning |
Previous Message | Simon Riggs | 2009-01-27 17:48:56 | Re: Hot standby, recovery infrastructure |