Aha, teď konečně ten dotaz dává smysl.
pokud máš nenulový počet uživatelů, co mají nutkavou potřebu do tabulek lézt nějakým tim table view čumítkem a tyto klikátka chtějí zkrátka primární klíč na tabulce. Bez něj buď odmítnou zobrazit nebo se podivně pošahají, když v tabulce je 500M+ řádků. To je jediný důvod, proč byla snaha přidat primární klíč.
Chápu, takže vy tyhle uživatele chcete potrestat. Uznávám, dát jim jako primární klíč složený klíč, jehož polovina bude půlka jiného sloupečku, a ještě to bude datum a čas, to je velmi rafinované. Ještě bych něco udělal s tou první půlku, integer je moc fádní – co takhle nějaký geospatial typ?
Nevýhoda tohohle trestu je to, že trestáte i sám sebe. Pokud se trestat nechcete, o typech SERIAL/BIGSERIAL sám píšete.
Nu, stejná skupina má občas snahu psát dotazy, kde do where nacpou něco jako "lower(casr) between T1 and T2", tak jsem chtěl zabít dvě mouchy jedním klíčem, že by jim to trochu zrychlilo, když nejsou schopni pochopit range operaci typu casr && (T1, T2]. :-)
Pokud by v tom dotazu nebyla i podmínka na
smid, ten index by se neuplatnil.
Samozřejmě to jde řešit, že místo casr:tstzrange použít na to 3 samostatné sloupce (casl:timestamp, casu:timestamp, casb:char(2)) a vyrobit si nad tím primary index pomocí (smid, casl, casb) a kontrola nepřekrývání pomocí "exclude using gist (smid with =, tstzrange(casl, casu, casb) with &&)" funguje, akorát pak některé operace to nechtělo brát dle toho indexu na pozadí. Dotaz typu "select * from tab where tstzrange(casl, casu, casb) && '[ T1, T2]'" nechtěl použít index toho exclude, což při použití normálního range sloupce fungovalo. A historicky je to děláno vše na range, tak jsem nechtěl do toho tak hluboce rejpat.
V aktuálních verzích PostgreSQL by to mělo jít řešit generovanými sloupci. Obávám se, že kombinace
stará databáze + uživatelé, kteří neumí psát SQL dotazy + velký objem dat je smrtelná a pokud jednu z těch věcí nevyřešíte, volil bych umělý primární klíč i za cenu toho, že tím na disku vznikne nový velký index. Tu verzi databáze ani uživatele jste si asi nevybral, tak si nekomplikujte život indexem, který stejně nikdo neocení u bude dělat problémy vám i těm uživatelům s čumítky.
Zobrazit příspěvky
