Are we done with the sort interrupt issue mentioned in the subject line, and the issue outlined below?
--------------------------------------------------------------------------- Tom Lane wrote: > "Charles Duffy" <[EMAIL PROTECTED]> writes: > > ... For the 'long' data, the compare moves on rightward until it > > encounters 'flato', which is a TEXT column with an average length of > > 7.5k characters (with some rows up to 400k). The first 6 columns are > > mostly INTEGER, so compares on them are relatively inexpensive. All > > the expensive compares on 'flato' account for the disproportionate > > difference in sort times, relative to the number of rows in each set. > > Yeah, and it's not just that it's text either. At those sizes, all > the values will be toasted, which means each compare is paying the > price of fetching multiple rows from the toast table. And decompressing > them too, no doubt. These costs are most likely swamping the actual > strcoll() (not that that's not bad enough compared to int4cmp). > > We could probably tweak the sorting code to forcibly detoast sort keys > before beginning the sort, but I'm not entirely convinced that would be > a win: reading and writing enormous sort keys won't be cheap either. > > Meanwhile, for a cheap solution: do you really need to sort on flato > at all? Maybe sorting on substr(flato,1,100) would be good enough? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
