sybase: problem s order by ... DESC (jeste delsi)

[Pavel Kolesnikov]

Jan Serak <sherry na pikebo.cz> wrote:

:> Mam aplikaci, ktera nad nemalou tabulkou casto provadi dotazy typu:
:> 
:>     SELECT * from TABLE WHERE b_id = xxx ORDER BY posted DESC
:> 
:> (b_id i posted jsou indexovany, posted obsahuje datetime, kdy byl
:> dany zaznam vlozen do databaze).
:> 
:> Tyto dotazy obcas trvaji velmi velmi dlouho, a zjevne je to tim,
:> ze se nepouziva index nad "posted" - showplan mi totiz tvrdi, ze
:> nejprve dochazi k insertu do worktable, a az pote k selectu,
:> narozdil od trideni "ASC", kde ukazuje, ze se rovnou vybira.

: a) pokud mate index nad b_id a jiny index nad posted, tak vzdy
: pro pristup do tabulky lze pouzit nejvyse jeden jediny index.

Mozna jsem to zbytecne zkomplikoval. V one tabulce mam i dvojity
index pres b_id a posted. Stejny problem ale pozoruji i pri prostem 

	SELECT * FROM table ORDER BY posted DESC

kde je nad "posted" jednoduchy index.

Proste ocekaval bych, ze se ten index pri trizeni pouzije.

Pri listovani moudrymi knihami jsme tu nakonec narazili na stranku
http://manuals.sybase.com:80/onlinebooks/group-as/srg1100e/sqlsrvpt/@Generic__BookTextView/7550;nh=1;pt=7550;lang=cs;uf=0?DwebQuery=desc&DwebSearchAll=1#X
kde se pomerne nesmlouvave pravi:

	"The use of desc in an order by clause, to get results in
	descending order, always requires a sort."

Prijde mi divne, ze by Sybase SQL server byl nejak mimoradne hloupy,
takze chyba bude asi na me strane a skutecnost, ze ORDER BY DESC
proste indexy nemuze pouzit je nejaky notoricky znamy a logicky
zduvodnitelny fakt platny pro vetsinu SQL serveru - je tomu tak?

: Neznam sybase, ale principialne se vzdy selecty s order by musi
: provadet tak, ze se data vyberou a pak setridi. Jestli se pred
: tridenim ulozi nekam do docasnych struktur v databazi nebo
: nekam do pameti je vcelku lhostejne.

To nesouhlasim nebo aspon neco nechapu:

Pokud si dam set showplan on (tj. neco jako explain, proste popis
toho, co se zrovna deje :), tak pri provadeni ORDER BY (ASC) ma query
plan pouze jeden krok, a to 

	STEP 1
		The type of query is SELECT.
		FROM TABLE article
		Nested iteration.
		Index : article_posted_ind
		Ascending scan.
		Positioning at index start.
		Using I/O Size 2 Kbytes.
		With LRU Buffer Replacement Strategy.
	
Kdezto pri SELECT * FROM table ORDER BY posted DESC dochazi k tomuto:


	STEP 1
		The type of query is INSERT.
		The update mode is direct.
		Worktable1 created for ORDER BY.
		FROM TABLE article
		Nested iteration.
		Table Scan.
		Ascending scan.
		Positioning at start of table.
		Using I/O Size 8 Kbytes.
		With MRU Buffer Replacement Strategy.
		TO TABLE Worktable1.

	STEP 2
		The type of query is SELECT.
		This step involves sorting.
		FROM TABLE
		Worktable1.
		Using GETSORTED
		Table Scan.
		Ascending scan.
		<ted se to pochopitelne chvilku kousne>
		Positioning at start of table.
		Using I/O Size 4 Kbytes.
		With MRU Buffer Replacement Strategy.
		<opet pauza a pak se sypou data>

Z toho bych si dovolil odvodit, ze pokud mam pouzitelny index, tak
SQL server umi jit podle indexu a v jednom kroku tedy vracet data 
jiz setrizena. Asi nemam ten vhled aby mi bylo jasne, ze po indexu
se neda chodit pozpatku - proc?
			
:> Neprilis ciste metody, ktere me napadaji, jsou treba "odhadnout",
:> ze zaznamy, ktere me zajimaji, nejsou starsi nez xyz hodin, a tim
:> zmensit tridenou mnozinu.

: Nevim, co je necisteho na:

: 	select ... from ... where b_id=xyz and posted>sysdate-3

: pokud me nezajimaji data starsi tri dnu (omlouvam se, sysdate-3
: lze pravdepodobne pouzit pouze v Oracle). Pokud jsou v tabulce
: data za posledni rok, muze to samozrejme VELMI pomoci.

No, problem je prave v tom, ze zaznamy do inkriminovane tabulky 
pribyvaji dost nepravidelne. Tzn. napr. pro b_id = 1 je vhodne
to omezit tremi dny zpet, ale treba pro b_id = 2 maji smysl dva
mesice. 

: Ohledne indexovani offsetu od pulnoci 1. 1. 3000: neverim, ze by Vam
: to mohlo nejak vyrazne pomoci. Tridit se musi tak jako tak.

Pokud je normalni, ze databaze umi vyuzit indexu jen jednim smerem, 
tak mi to pochopitelne pomuze, protoze tim si vlastne vytvorim
prevracene usporadany index :)

Ted jeste jeden Sybase specificky kousicek - pri studiu moudrych 
knich jsem se dozvedel o funkci "sp_statistics", ktera mi povyklada
o indexech a jejich vlastnostech. Jeden s parametru, ktere tato
funkce u indexu sdeluje, je "collation". Jak podle EnCz slovniku,
tak podle toho, ze tato vlastnost nabyva hodnot 'A' a 'D' ve 
vyznamu "ascending" a "descending", mam dojem, ze to nejak souvisi
se "smerem" setrideni indexu. Pritom ale u CREATE INDEX jsem se
o nastavovani podobnych vlastnosti nic nedocetl. Nevite nahodou
nekdo, co se tim "collation" mysli?

Diky za dosud dosle i budouci komentare.

  Pavel