Re: [PATCHES] putting CHECK_FOR_INTERRUPTS in

Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?

---------------------------------------------------------------------------

Tom Lane wrote:
> "Charles Duffy" <charles.duffy@gmail.com> 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   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +