SQL Server 2012 enhanced the performance of INDEX REBUILD by introducing the SORT_IN_TEMPDB option.
I observed that many SQL developers are not using this feature or maybe they don’t know about it.

The INDEX REBUILD operation is removing the fragmentation of indexes which improves the query performance. It scans the data pages of base table to retrieve the key values and builds an index leaf row for each row.

This process requires internal sorting which it stores in the buffer area.

Once the buffer filled with leaf index entries, it stores the sorted result into a disk as an intermediate sort run. Next, It again starts with the same process for further data pages.

As per the MSDN,

When you create or rebuild an index, by setting the SORT_IN_TEMPDB option to ON you can direct the SQL Server Database Engine to use tempdb to store the intermediate sort results that are used to build the index.

Although this option increases the amount of temporary disk space that is used to create an index, the option could reduce the time that is required to create or rebuild an index when tempdb is on a set of disks different from that of the user database.

If SORT_IN_TEMPDB is set to ON, there must be sufficient free space in tempdb to store the collection of sort runs for the largest index.

When you are rebuilding the large size of Indexes, SORT_IN_TEMPDB helps you lot by reducing the operational execution time.

Sample Script with option SORT_IN_TEMPDB:

ALTER INDEX ALL ON MyTableName
REBUILD WITH 
(FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
 STATISTICS_NORECOMPUTE = ON);
GO

Yesterday, I was doing performance tuning for one our long running queries. I have checked the execution plan of the query and found that query sort operations are spilling to disk instead of fitting in memory.

Every time, just tuning the Table Indexes should not be the ultimate solution to improve the query performance.

There are always N factors behind the bad performance shape of your query.

How can you know that your operations are spilling to disk?

When you execute EXPLAIN ANALYZE for your query and if you see a line like Sort Method: external merge Disk: 88342kB, your operations are spilling to disk.

Is spilling to disk a bad operation?

Yes: Because it requires more CPU/IO for the disk operation and it leads to biggest performance cause.

What is the solution?

The simple solution is, validate the configuration of a work_mem parameter.
If you do a lot of complex sorts and have a lot of memory, then increasing the work_mem parameter allows PostgreSQL to do larger in-memory sorts which, unsurprisingly, will be faster than disk-based equivalents.

How can you configure work_mem?

A work_mem of at least 16MB would keep the intermediate data in memory and likely improve the query response time.
You can set at the server level for the general use (in postgresql.conf).

You can also set at your session level using below sample query. Increase the setting until you see Memory instead of Disk in the EXPLAIN output.

BEGIN;

SET LOCAL work_mem = '50MB';

SELECT *FROM Table_Name;

COMMIT;