[HACKERS] Questionable coding in orderedsetaggs.c
In ordered_set_startup() sorts are initialised in non-randomAccess mode (tuplesort_begin_heap() and ~datum(), last argument). The use of tuplesort_skip_tuples() feels very like a random access to me. I think it doesn't fail because the only use (and implementation) is to skip forwards; if backwards were tried (as the interface permits) external sorts would fail because multiple tapes are present for FINALMERGE. -- Cheers, Jeremy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Questionable coding in orderedsetaggs.c
Jeremy Harris j...@wizmail.org writes: In ordered_set_startup() sorts are initialised in non-randomAccess mode (tuplesort_begin_heap() and ~datum(), last argument). The use of tuplesort_skip_tuples() feels very like a random access to me. I think it doesn't fail because the only use (and implementation) is to skip forwards; if backwards were tried (as the interface permits) external sorts would fail because multiple tapes are present for FINALMERGE. Well, we certainly don't want to incur the overhead of randomAccess mode when we're not actually going to use it, so I'd resist changing the code in ordered_set_startup(). It's true that if tuplesort_skip_tuples() supported backwards skip, it would need to insist that randomAccess mode be enabled *when a backwards skip is used*. But such a feature is purely hypothetical ATM. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Questionable coding in orderedsetaggs.c
On Sunday, January 26, 2014, Tom Lane t...@sss.pgh.pa.us wrote: Jeremy Harris j...@wizmail.org javascript:; writes: In ordered_set_startup() sorts are initialised in non-randomAccess mode (tuplesort_begin_heap() and ~datum(), last argument). The use of tuplesort_skip_tuples() feels very like a random access to me. I think it doesn't fail because the only use (and implementation) is to skip forwards; if backwards were tried (as the interface permits) external sorts would fail because multiple tapes are present for FINALMERGE. Well, we certainly don't want to incur the overhead of randomAccess mode when we're not actually going to use it, so I'd resist changing the code in ordered_set_startup(). It's true that if tuplesort_skip_tuples() supported backwards skip, it would need to insist that randomAccess mode be enabled *when a backwards skip is used*. But such a feature is purely hypothetical ATM. +1 In ordered set functions, we normally don't skip backwards and skip tuples while sorting in,for e.g. Hypothetical set functions in only a forward manner. -- Regards, Atri *l'apprenant*
