Bug 6538 - transient BAT/COL/Heap-allocation fall-back to DBfarm in case DBextra fails
Summary: transient BAT/COL/Heap-allocation fall-back to DBfarm in case DBextra fails
Status: NEW
Alias: None
Product: GDK kernel
Classification: Unclassified
Component: all (show other bugs)
Version: -- development
Hardware: All All
: Normal enhancement
Assignee: GDK devs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-08 16:14 CET by Stefan Manegold
Modified: 2018-02-08 16:14 CET (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Manegold cwiconfidential 2018-02-08 16:14:29 CET
Having a DBextra for transient storage separate from DBfarm for persistent storage is a great feature!

A very common and beneficial scenario is to have the transient DBextra on the fastest storage (e.g., NVMe of at least SSD), while the persistent DBfarm is on an "ordinary" disk RAID / JBOD / ...

However, the capacity of the fastest flash storage is usually considerably smaller than that of the disk storage.

In such cases, queries that process large amounts of data, and thus need to allocate large intermediate results, might fail given that transient intermediate result allocation is limited by the fast flash storage capacity.

One way to avoid query failures in such cases could be to have the allocation for transient intermediate results fall back to DBfarm in case allocation on DBextra fails. This could be either an automatics and transparent default, or an explicit configuration option of the server.

Thanks!