| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Using quicksort for every external sort run |
| Date: | 2015-09-06 09:41:34 |
| Message-ID: | CAM3SWZSo5wB0=9tT9ZwojRQhRXXkbMnqNcqtCLV-QnpUqJcUOg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Sep 6, 2015 at 1:51 AM, Marc Mamin <M(dot)Mamin(at)intershop(dot)de> wrote:
> Have you considered performances for cases where multiple CREATE INDEX are running in parallel?
> One of our typical use case are large daily tables (50-300 Mio rows) with up to 6 index creations
> that start simultaneously.
> Our servers have 40-60 GB RAM , ca. 12 CPUs and we set maintenance mem to 1-2 GB for this.
> If the create index themselves start using parallelism, I guess that we might need to review our workflow...
Not particularly. I imagine that that case would be helped a lot here
(probably more than a simpler case involving only one CREATE INDEX),
because each core would be require fewer main memory accesses overall.
Maybe you can test it and let us know how it goes.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2015-09-06 09:54:08 | Re: [PATCH] SQL function to report log message |
| Previous Message | Marc Mamin | 2015-09-06 08:51:20 | Re: Using quicksort for every external sort run |