| From: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | 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 08:51:20 |
| Message-ID: | B6F6FD62F2624C4C9916AC0175D56D88420729E0@jenmbs02.ad.intershop.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>I will sketch a simple implementation of parallel sorting based on the
>patch series that may be workable, and requires relatively little
>implementation effort compare to other ideas that were raised at
>various times:
Hello,
I've only a very superficial understanding on your work,
please apologize if this is off topic or if this was already discussed...
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...
best regards,
Marc Mamin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-09-06 09:41:34 | Re: Using quicksort for every external sort run |
| Previous Message | Tomas Vondra | 2015-09-06 08:46:13 | Re: Multi-column distinctness. |