| 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: | Whole Thread | Raw Message | 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 |