Hirdetés
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- One mobilszolgáltatások
- A Redmi is hozott kompakt táblagépet
- Hivatalos a OnePlus Watch 4
- Xiaomi 15T Pro - a téma nincs lezárva
- Samsung Galaxy S26 Ultra - fontossági sorrend
- Samsung Galaxy A57 - kecses test, lusta lélek
- Távozik az Apple vezérigazgatója
Új hozzászólás Aktív témák
-
updog
őstag
A válasz: attól függ
Ha DATE típusú a meződ, és indexált, akkor nyilván ha egy DATE-tel hasonlítod össze (TO_DATE), akkor végigrohan az indexen és kidobja amit keresel.Ellenben ha ezt a meződ TO_CHAR-ozod, nem fogja tudni használni az indexet. (pl.) Oracle-ben itt lehet csavarni egyet a dolgon function based indexszel, csinálhatsz olyan indexet, ami nem a mezőt, hanem a TO_CHAR(mező)-t indexeli, akkor ugyanolyan gyors lesz.
Amúgy ha nem lenne index a mezőn, kb. mindegy lenne performancia szempontból, praktikusan a TO_DATE(feltétel)-t szokták használni, ha a mező DATE.
(#3618) -Zeratul- jepp.
Egyszer én is futottam egy hasonlóba (DATE mezőn volt index, és TO_CHAR-ozták, hogy egy string-gel összehasonlítsák... Mekkora volt az öröm mikor mutattam hogy 500%-os performancia javulás történt, miután átírtam 
-
bpx
őstag
Az első változatot irtani kell.
Nem az átalakítás a nagy munka, hanem az, hogy ha index van az oszlopon, akkor az tipikusan a tábla.dátum_mező-re van, és nem pedig a to_char(tábla.dátum_mező...)-re, így a lekérdezés nem tudja használni az indexet, teljes táblát olvas, lassú. Persze lehet function based indexet létrehozni a to_char(tábla.dátum_mező...)-re is, de erre az esetre nem ez a helyes megoldás.
Ezen kívül az ilyen átalakításoknál az optimizer számosságbecslései is pontatlanak lehetnek, hiszen dátum típusnál tudja, hogy pl. 2017-01-01 előtt a 2016-12-31 van, de ha ugyanezt stringként kell becsülni, akkor olyan értékek is lehetségesek, amelyek dátumnál nem, pl. 2017-00AAAAAA, 2016-999990000, stb.
-
bpx
őstag
semmi jelentősége nincs, hogy a dátum milyen formátumban van ábrázolva, a dátum a tárolása a háttérben máshogy történik, szűrni úgy lehet, hogy egy másik dátumhoz hasonlítod:
SELECT * FROM tabla WHERE datum = TO_DATE('YYYY-MM-DD HH24:MI:SS', '2012-06-27 22:52:12');
ha a dátum karaktersorozatként van tárolva, az már régen rossz, és akkor kell string műveletekkel foglalkozni
illetve ebben semmi PL/SQL nincs, szóval érdekelne, milyen az a PL/SQL-es szűrés/és hogy mire gondoltál
Új hozzászólás Aktív témák
Hirdetés
- Eredeti játékok OFF topik
- Crimson Desert
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Egyre kevesebb döntést hagy az AI az ember kezében
- Xbox tulajok OFF topicja
- Eljött a CPU-k kora az AI-piacon
- Graphics: Telefonvásárlási kálváriám....avagy clickbait cím: Horror a hardveraprón
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- Milyen okostelefont vegyek?
- Autós topik
- További aktív témák...
- 27% - ASUS TUF Gaming VG27AQ1A IPS Monitor! 2560x1440 / 170Hz / 1ms / G-Sync / FreeSync
- Nvidia Quadro M2000/ P2000/ P4000/ P5000/ RTX 4000/ RTX 5000/ RTX A2000
- Lenovo Thinkpad L490,HD,14",i5-8365U,8GB DDR4,256GB SSD,WIN11
- Lenovo ThinkPad X1 Active Noise Cancellation fejhallgató
- Bomba ár! Asus ZenBook UX433 - i7-10G I 16GB I 512SSD I 14" FHD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest

Ha DATE típusú a meződ, és indexált, akkor nyilván ha egy DATE-tel hasonlítod össze (TO_DATE), akkor végigrohan az indexen és kidobja amit keresel.
Egyszer én is futottam egy hasonlóba (DATE mezőn volt index, és TO_CHAR-ozták, hogy egy string-gel összehasonlítsák... Mekkora volt az öröm mikor mutattam hogy 500%-os performancia javulás történt, miután átírtam 

