Bad Performance of Merge Join

Question

We are on ASE 15.0.3/EBF 21284 ESD#4.3 working on a application with over 3000 stored procedures.
Our server optimization goal is allrows_mix.
The Merge-Join is giving us problems. When a query uses Merge-Join, it usually take an order of magnitude longer to run than if we force it
to use the other types of joins - nested-loop, n-ary-nested-loop, or hash-join.
The query plan shows sorting on worktables leading into the merge-join.
I know I can disable it with "set merge_join off", or "set plan optgoal allrows_oltp", but I'd rather not if I can fix the problem instead.
Question: Are there configuration options that would help merge-join?
I've done variations of this:
sp_configure "number of sort buffers", 32000
I've also done variations of this in the proc:
set parallel_degree 5
set scan_parallel_degree 4
When I run the following command, I see sort buffer starvation:
1> sp_monitorconfig "sort buffers"
2> go
Usage information at date and time: Apr 24 2014  2:31PM.
Name                            Num_free    Num_active  Pct_act   Max_Used    Reuse_cnt
number of sort buffers                0               82045   100.00           82045                  0
(1 row affected)
(return status = 0)
Maybe there are other configuration option to help merge-joins? Any ideas?
Thanks.

Answer 1

Well, I'm gonna have to emphatically disagree with your comment ...
"regressing back to allrows_oltp setting to solve your performance problems should not be encouraged"
For *EVERY* client I've worked with on migrating from ASE 12.5.x to ASE 15.x ... they all had the same objective ... get through the migration as quickly as possible and do not degrade the performance of our database queries.  Unfortunately for every client I've worked with ... ASE 15.x, and the default of allrows_mix, did just the opposite, ie, migrations took much longer than expected/planned due primarily to huge performance degradation across their SQL inventory.
For most of my clients merge joins were rarely, if ever, used in ASE 12.5.x.  And since hash joins never existed, that leaves us with using nested loop joins in ASE 15.x in an attempt to stay as close to ASE 12.5.x in terms of performance.
NOTE: No, I don't consider compatibility mode as a solution as this requires you go through 2 migrations ... once to compatibility mode ... and eventually once to get off of compatibility mode.
Now, can merge joins improve the performance of *some* queries?  Absolutely, but in practice ... especially with the first 4-5 years of ASE 15.x releases ... merge joins caused more headaches and performance degradation than they were worth.  I've seen too many clients spend huge amounts of time trying to re-write code to work with merge joins, often failing and having to 'regress back' to nested loop joins in the end.
Unfortunately a) Sybase delivered ASE 15.x with allows_mix as the default and b) most companies didn't have enough migration experience to understand the pitfalls of trying to run all of their queries under the default of allrows_mix.  This meant that many companies were left having to 'regress back' to alternative solutions (eg, allrows_oltp, compat mode, don't migrate, move to another RDBMS) to address the performance degradation introduced with ASE 15.x and the default setting of allrows_mix.