Search Postgresql Archives

Re: Should pg 11 use a lot more memory building an spgist index?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 26, 2018 at 13:44:07 +0100,
 Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Bruno Wolff III <bruno@xxxxxxxx> writes:

As a short term work around, could I create the index first and use
insert statements, each in their own transaction, to get the table loaded
with the index?

Yes; it might also be that you don't even need to break it up into
separate statements.

It was time to refresh the geolite data anyway so I tried this. I needed to turn memory_overcommit back on (0) to avoid an error, but the load went OK without the oom killer doing anything. So things are fully working again.

Thanks for your help.

Is the issue on Fedora taking very long to build a normal spgist index for
network addresses worth pursuing separately, or is it likely to be the same
underlying cause?

This issue only applies if it was an exclusion constraint.  If you saw
slowness or bloat with a plain index, that would be worth investigating
separately.

I'll start a seperate thread if I get something to reasonably ask about. The current dataset is probably a lot larger then needed to demonstrate the issue. The difference might be do to configuration or how Fedora built it. And I'll want to compare back to version 10. In the end I'll probably ask why it is slower in one case as opposed to the other and it might not even be a real bug.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux