Administrace komentářů

Hele, proč tvrdíš takový blbiny, když stačí např. jeden pohled do manuálu k databázi k ověření: http://www.postgresql.org/docs/8.0/static/storage-page-layout.html Samozřejmě, že se mazání dat označuje nejen do metadat, ale i do samotnejch stránek - konkrétně při mazání musíš vyplnit TXID mazající transakce. Dyk už to je směšný: do krve mě tady o něčem přesvědčuješ, ale cokoli řekneš o architektuře db, tak je blbě. V MYSQL jsou data uložený přímo B+stromě clustrovanýho indexu, takže opět při mazání se mění přímo datová stránka na které je záznam uložen.

Ohledně testu na více dotazů: co přesně jste zvoral nevím, v čerstvé databázi se může pokazit cokoli. Např. třeba může vadit právě ta podmínka between, protože ještě není v paměti index. Když se to nedělá na čerstvé databázi, čili v reálných podmínkách, čas vyjde stejnej, když se to nevolá z PLPGSQL kódu, kde je větší režije, tak je čas lepší pro víc dotazů, kdybys to volal jako n příkazů, tak ještě navíc plus režie přenosu. Už jste si zkusil ty SQL funkce?

Založení databáze je založení databáze. Příkaz CREATE. Pokud nad ní děláte ještě něco dalšího (vkládáte data, analyzujete), už to není čerstvě založená databáze. Nicméně přestaňme se hádat nad slovíčky: uznávám, že jsem Vás podezíral z větší blbosti než jste ve skutečnosti udělal, nicméně furt si stojím za to, že to, jak jste nastavil testcase je blbost furt. Jen ne tak velká

Zkus ty data porovnat nad nějakými reálnými daty... to myslíš vážně? To fakt nejsi schopnej alespoň základní abstrakce? Samozřejmě, že když budu hledat data danýho uživatele s rozmezím daných dnů, tak založím index (userid, den), mění to něco? A pokud sloupec B vyjadřuje nějak zakódované userid + den, co je na těch datech nereálného? Tak si to zkus, dokonce todle vyjde i na čerstvý tabulce, odkomentuj a zakomentuj to between:

drop table bench ;drop table bench ;
CREATE TABLE bench
(
a integer primary key,
b integer, /*userid*/
c integer, /*den*/
constraint uniq unique(b,c)
);

insert into bench(a,b,c) select (r % 2) * 100000 + (r/2), r / 100,  r % 100 from generate_series(1,100000) u(r);
analyze bench;

explain analyze select count(a) from test.bench Where a in (4475,104475,4476,104476,4477,104477,4478,104478,4479,104479)  
/*AND b=89 AND c  BETWEEN 50 AND 50+10*/
;


explain analyze select count(a) from test.bench Where a in (3215,103215,3216,103216,3217,103217,3218,103218,3219,103219)   
/*AND b=64 AND c  BETWEEN 30 AND 30+10*/

To je úplně m modelovej případ - edituju nějakej subset dní z uživatele, idčka jsou trochu rozházený. A to je těch záznamů jen deset, s vzrůstajícím počtem je intervalovej dotaz efektivnější.

Píšeš předčasná optimalizace: Takže už začínáš uznávat, že to je lepší řešení? Nebo je to jen odvádění od tématu? O tom, zdali a jak moc se to vyplatí jsem nepsal, jen jsem tvrdil, že je to rychlejší, což jsi popíral. Opět se snažíš vykroutit tím, že polemizuješ s něčím jiným, než co tvrdím.

Nicméně pokud tedy tvrdíš, že to je předčasná optimalizace, tak je evidentně výkonu dost, čili vyhovuje nejrychleji napsané řešení. Vzhledem k tomu, že jsi už tuším uznal, že mé řešení je kratší, takže to znamená, že je pro první nástřel lepší.