Názor k článku Používání indexů v PostgreSQL: krátce a pro začátečníky od jkb - no, ja jsem mluvil obecne o vetsine databazi....

no, ja jsem mluvil obecne o vetsine databazi. Napr. v cervnu psal kolega nasledujici:

tabulka ma 12 milionu radku , mssql 2008, server 12 GB memory:

CREATE TABLE eav_einnahmen2(
id uniqueidentifier NOT NULL,
jahr int NULL,
monat int NULL,
vu tinyint NULL,
version tinyint NULL,
tz_ein smallint NULL,
gem_ein smallint NULL,
hs_ein int NULL,
tz_aus smallint NULL,
gem_aus smallint NULL,
hs_aus int NULL,
weg smallint NULL,
fs smallint NULL,
ps smallint NULL,
preis decimal(18, 2) NULL,
anzahl smallint NULL,
datum_kauf date NULL,
uhrzeit_kauf time(7) NULL,
datum_fahrt date NULL,
vw smallint NULL,
geraete_nr nvarchar(50) NULL,
ticket_nr nvarchar(50) NULL,
zahlung smallint NULL,
kunden_id nvarchar(50) NULL,
status int NULL,
original varchar(255) NOT NULL,
id_datei int NOT NULL,
PRIMARY KEY CLUSTERED
(
id ASC
)
);

CREATE NONCLUSTERED INDEX einnahmen_datei ON eav_einnahmen2
(
id_datei ASC
);

Zadne dalsi foreign keys, trigger. Pres prikaz:

delete from eav_einnahmen where id_datei=xxx;

se smaze 317271 radek cas: 6:32 min

select COUNT(*) from eav_einnahmen where id_datei=xxx ... cas nekolik milisekund

select * from eav_einnahmen where id_datei=xxx ... cas: 43 sekund

Jak je videt, problemy ma nejen Oracle.

Ted tedy k tomu b-tree. Podle me vyrobci databazi nijak zvlast neoptimalizuji ten DELETE ve spojitosti s tim b-tree, dival jsem se u tech jednodussich (sqlite, myisam) a tam se proste ten strom preorganizuje jak je to napsane v kazde ucebnici. Nevim nakolik pouzivaji ty vetsi db bulk-loading, coz je v takovych pripadech potreba, ale ono to asi neni tak jednoduche, protoze ta manipulace s tim stromem se neda oddelit od toho transakcniho zpracovani a to byla vlastne moje myslenka, ze v pripade DELETE je v tom asi nejaky zasadni problem.

Nakonec ono staci si zadat v google 'delet sql slow' a clovek vidi, kolik lidi se s tim pere.