Új hozzászólás Aktív témák

• #17484 #39560925 törölt tag

  Új Válasz 2025-04-24 08:55:00 #17484

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  Hadd írjak le egy rövid személyes tapasztalatot a Gemini 2.5 Pro-val és hogy miért látom úgy hogy rövid időn belül nagy felfordulás lesz a programozói szakmában.

  Jelenleg egy relatíve nagy adatbázis migrációján dolgozok, postgresről oraclere. Van 2 tábla is több mint 1 millárd recorddal, meg sok kisebb. Felmerült hogy dátum alapján lehetne particionálni, hogy könnyű legyen régebbi rekordokat archiválni, különben csak örökké nőni fognak a táblák.

  Gemininek beküldtem a sémát, leírtam neki hogy milyen particiókat akarok, és beküldtem neki a legtöbb CPU-t igénylő queryket, hogy analizálja milyen negatív hatással lesznek a partíciók.

  Ahogy nézem az analízist, láttam hogy egy olyan partition pruningot alkalmaz majd szerinte az oracle, amit úgy gondoltam hallucinál. Felhívtam rá a figyelmét, elkezdtem challengelni, majd Oracle dokumentációból is hoztam neki példát, hogy szerintem miért nem fog ennél a joinnál pruneolni. Válasz részlet a harmadik challenge attempt után:

  You are absolutely right to demand concrete evidence for this specific optimizer behavior, as it's a nuanced point and not as explicitly documented with a single sentence as, say, basic filter predicate pruning. Finding a direct quote saying "Oracle will use column A from table T1 to prune partitions defined by column B on table T2 when joining on column C" is indeed difficult.

  The evidence lies more in understanding the principles of the Cost-Based Optimizer (CBO), how it handles joins (especially Nested Loops), and how partition pruning works dynamically, rather than a single explicit statement covering this exact join vs. partition key scenario.

  Why is it hard to find a direct quote?
  Documentation often describes features (partitioning, joins) and mechanisms (pruning, access paths) separately. Explaining every single interaction between all features would make the documentation impossibly long. The behavior emerges from the combination of these standard mechanisms.

  Később tovább challengeltem a kollégámmal, és Gemini nem engedett az igazából, hozott még egy metaforikus példát is ami hibátlanul illeszkedik az esetre.

  Lenyűgöző az intelligenciája, sokkal jobban ért a témához mint én. Hogyis ne értene jobban, nekem van 8 év tapasztalatom amiből oracle CBO-jával 0. Nem ismerhetem az összes nuanced viselkedést.

  Ezen a héten is lenyűgözött, ezúttal implementáció során. Épp átírom a migrációt végrehajtó kódot több szálúra, nagy táblák ráadásul több chunkra vannak szedve, de a táblák között dependenciák vannak, úgyhogy azokat tiszteletben tartva lehet csak ütemezni a table chunkok végrehajtását.

  Lekódoltam a poc changet, beküldtem neki, leírtam mik a requirememtek és visszaküldte a kódot production readyre megírva, az összes hibát a poc-ban kijavítva, olyan minőségi munkát végzett amit megírni legalább 1-2 hét lett volna, de ehelyett par prompt volt.

  Kicsit itt is vitatkozni kellett vele mert semaphoret meg count down latchet használt volna ami túl low level, de meggyőztem hogy alkalmazza az input / output blocking queuekat inkább a task submissionre, és tökéletes lett.

  Literálisan 2 hétnyi munkát megcsinált pár óra alatt, amiből neki a tényleges válasz generálás pár perc volt (én voltam a bottleneck).

  Amikor egy tool ilyen intelligens, hogy jobb a fejlesztők 99%-ánál a feladatok 99%-ában, akkor tényleg már csak annyi kell neki, hogy kapjon egy kis agentic traininget.

  Ez 1 év múlva képes lesz arra, hogy MCP-n leszedi a szükséges contextet jiráról, confluenceről, elkezdi a munkát, ha kell feltesz tisztázó kérdéseket a fejlesztőnek és utána nyitja a pull requestet githubon MCP-vel.

Új hozzászólás Aktív témák