| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Using quicksort for every external sort run |
| Date: | 2016-04-03 21:06:34 |
| Message-ID: | CAM3SWZQj4i=ZMbxdpjdZjR-CY+OvLpb0=K5exW2Gs5LDUu8tFQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I just mean that, as you say, trace_sort is described in the documentation.
I don't think we'll end up with any kind of cost model here, so where that
would need to happen is only an academic matter. The create index parameter
would only be an option for the DBA. That's about the only case I can see
working for replacement selection: where indexes can be created with very
little memory quickly, by optimistically starting to write out the start of
the final index representation almost immediately, before most of the
underlying table has even been read in.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2016-04-03 21:09:11 | Re: snapshot too old, configured by time |
| Previous Message | Tom Lane | 2016-04-03 20:53:17 | Re: More stable query plans via more predictable column statistics |