Why databases use ordered indexes but programming uses hash tables

Re:Why databases use ordered indexes but programming uses ha... by cperciva on Tuesday December 10, 2019 @01:36AM (#21750225)

In addition to the limited number of cache slots available for superpages (varies depending on cpu), remember that those can be invalidated (again, depending on cpu). If you're ping-ponging processes on a single CPU, you won't necessarily have what you need in the TLB.

[ Parent | on HN ]

Re:Why databases use ordered indexes but programming uses ha... by davedx on Tuesday December 10, 2019 @01:51AM (#21750285)

> If you're ping-ponging processes on a single CPU, you won't necessarily have what you need in the TLB.

Is that really likely on a production database server?

[ Parent | on HN ]

Re:Why databases use ordered indexes but programming uses ha... by cperciva on Tuesday December 10, 2019 @02:25AM (#21750414)

Depends on the design. At a minimum you're ping-ponging between userland and kernel; but you might also be bouncing between a transport layer unwrapper, an authentication front-end, the database core, and a storage back-end.

[ Parent | on HN ]

Re:Why databases use ordered indexes but programming uses ha... by namibj on Wednesday December 11, 2019 @02:29AM (#21760371)

Ideally, with io_uring(2)/DPDK/SR-IOV-NVMe, you can skip enough syscalls to drop their performance impact below 1%.

[ Parent | on HN ]

Re:Why databases use ordered indexes but programming uses ha... by jdsully on Tuesday December 10, 2019 @02:37PM (#21756035)

Spectre may have changed things, but for a long time a user->kernel switch didn't imply a full TLB flush.

[ Parent | on HN ]