---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hejsa!

Jeg arbejder på en keyword-baseret søgemaskine til relationelle
databaser. Der skal ofte hentes en hel del rækker efter samme
'skabelon', dvs. det er kun primærnøgler, der varierer mellem de
enkelte forespørgsler. Hristidis, Gravano og Papakonstantinou [1]
benytter til dette formål PREPARE, hvor min egen fremgangsmåde indtil
nu har været at lave en større SELECT. Eksempel:

- -- Deres metode
PREPARE foo AS
SELECT * FROM a, b
WHERE
a.fk = b.pk
AND a.pk = $1
AND b.pk = $2

- -- Min metode
SELECT * FROM a, b
WHERE
a.fk = b.pk
AND a.pk IN (a1, a2,...,am)
AND b.pk IN (b1, b2,...,bn)
LIMIT k

Idéen her er, at det er de første k resultater, der skal bruges, og
med deres metode EXECUTE'er de forespørgslen k gange. Jeg er bevidst
om, at min metode ikke garanterer, at nogen orden bliver bevaret, men
'den virker' lige nu... eller ser i hvert fald ud til at gøre det. Den
skal nok omskrives en smule, men pyt med det lige nu.

Med deres metode sparer de naturligvis en del tid i forhold til hvis
de ikke brugte PREPARE overhovedet, men med PostgreSQL i en
forholdsvist lille database (~50 MB) får jeg ufravigeligt bedre
resultater med min egen metode, ligeledes med en 100 MB TPC-H DB. Er
der nogen, der kan lokkes til at dele nogle resultater med lignende
forespørgsler for andre DBMS'er?


Martin

Fodnoter:
[1] http://www.vldb.org/conf/2003/papers/S25P03.pdf

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkHuM74ACgkQYu1fMmOQldVdRQCfZNkiRC7bqseSjegMWTrv7W+N
1dEAoLMPTeWbkGGxT+acNMxhZ7fYb14n
=6q4+
-----END PGP SIGNATURE-----

---

Martin Christensen wrote:

> Jeg arbejder på en keyword-baseret søgemaskine til relationelle
> databaser. Der skal ofte hentes en hel del rækker efter samme
> 'skabelon', dvs. det er kun primærnøgler, der varierer mellem de
> enkelte forespørgsler. Hristidis, Gravano og Papakonstantinou [1]
> benytter til dette formål PREPARE, hvor min egen fremgangsmåde indtil
> nu har været at lave en større SELECT. Eksempel:
>
> - -- Deres metode
> PREPARE foo AS
> SELECT * FROM a, b
> WHERE
> a.fk = b.pk
> AND a.pk = $1
> AND b.pk = $2
>
> - -- Min metode
> SELECT * FROM a, b
> WHERE
> a.fk = b.pk
> AND a.pk IN (a1, a2,...,am)
> AND b.pk IN (b1, b2,...,bn)
> LIMIT k

Det eneste du sparer afaik ved nr 1. er parsing af sql statementet. Dvs
du skal parse det en gang, hvis du har behov for at køre det 1000 gange.

Om den ene where clause er bedre end den anden er op til optimizeren i
din database. Helt sikkert er det at jeg synes dit query er det pæneste
af de to sql wise.

Lad i øvrigt være med at lave en select *, og vælg kun de felter du
decideret har brug for. Ellers loader den alle kolonner der matcher ind
i dit sql segment.

Er der i øvrigt noget i vejen for at kombinere? Jeg kender ikke helt dit
dbms:

PREPARE FOO AS
SELECT foo,bar FROM a, b
WHERE
a.fk = b.pk
AND a.pk IN ($1,$2,$3,$n)
AND b.pk IN ($n+1,$n+2,$n+m)
LIMIT k

Mvh

Nikolaj Hansen

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> writes:

> Det eneste du sparer afaik ved nr 1. er parsing af sql statementet.
> Dvs du skal parse det en gang, hvis du har behov for at køre det
> 1000 gange.

Der er tale om både parsing, planlægning og omskrivning, så man sparer
lidt mere.

> Om den ene where clause er bedre end den anden er op til optimizeren i
> din database. Helt sikkert er det at jeg synes dit query er det
> pæneste af de to sql wise.

Både ja og nej. I sin nuværende form er det temmeligt grimt, at det
afhænger af en ordning, der ikke kan garanteres, og da især ikke i en
live database. Det skulle dog blot illustrere min pointe, og i sin
fulde form, er det lidt pænere, om end en anelse mere komplekst.

> Lad i øvrigt være med at lave en select *, og vælg kun de felter du
> decideret har brug for. Ellers loader den alle kolonner der matcher
> ind i dit sql segment.

Ahem... jeg har altså skrevet speciale i denne type søgemaskiner, og
efter de tilgængelige tal at dømme, har jeg også lavet verdens
hurtigste af sin slags, og er i gang med at forbedre hastigheden
yderligere. Jeg takker for de velmenende råd, meeeen...

> Er der i øvrigt noget i vejen for at kombinere? Jeg kender ikke helt
> dit dbms:
>
> PREPARE FOO AS
> SELECT foo,bar FROM a, b
> WHERE
> a.fk = b.pk
> AND a.pk IN ($1,$2,$3,$n)
> AND b.pk IN ($n+1,$n+2,$n+m)
> LIMIT k

Jo, det ville nok ikke være noget problem, men jeg tvivler på, at der
ville være alverden at hente ved det. Med lidt ordentlig planlægning
og indhentning af aktuel statistik om databasen, bliver det nok ikke
nødvendigt at udføre foo mere end en eller to gange alligevel, så der
vindes ikke så meget på det.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkHu+4QACgkQYu1fMmOQldWmIwCg4Zd4PzaocAvELJ8AXdJBT1QZ
UnIAn3LyyRXgyedROQAcZsJ/M3a9yTV1
=dKSp
-----END PGP SIGNATURE-----

---

Martin Christensen wrote:

>>Lad i øvrigt være med at lave en select *, og vælg kun de felter du
>>decideret har brug for. Ellers loader den alle kolonner der matcher
>>ind i dit sql segment.
>
>
> Ahem... jeg har altså skrevet speciale i denne type søgemaskiner, og
> efter de tilgængelige tal at dømme, har jeg også lavet verdens
> hurtigste af sin slags, og er i gang med at forbedre hastigheden
> yderligere. Jeg takker for de velmenende råd, meeeen...

Heh, og jeg er en stakkels klaphat der kun har arbejdet praktisk med
databaser i 10+ år.

Tag rådet eller lad være - det er da op til dig.

Hvis du bliver sur når du får de råd du selv spørger om, hvor så spørge
i det hele taget?

Faktum er, at hvis du har en applikation, og du bruger select * from foo
where bar=1, så kommer det tilsvarende resultsæt til at indeholde alle
kolonner fra tabellen hvor betingelsen er opfyldt. Hvis der er nogen.
Hvis du skriver select a,b from foo where bar=1, så kommer den til at
indeholde kolonne a og b. Ikke kolonne c som kan være eks. et mega stort
tekst felt eller en blob/clob.

Over and out.

mvh

Nikolaj Hansen

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> writes:

> Hvis du bliver sur når du får de råd du selv spørger om, hvor så
> spørge i det hele taget?

Nej, du misforstår, jeg har fulgt dit råd længe inden du gav det! Som
jeg sagde, var den forespørgsel, jeg gav som 'min metode' noget
forenklet. Jeg ville skam ikke virke bedre oplyst end dig, men blot
fortælle, at jeg har nogenlunde styr på grundprincipperne.

> Faktum er, at hvis du har en applikation, og du bruger select * from
> foo where bar=1, så kommer det tilsvarende resultsæt til at indeholde
> alle kolonner fra tabellen hvor betingelsen er opfyldt. Hvis der er
> nogen. Hvis du skriver select a,b from foo where bar=1, så kommer den
> til at indeholde kolonne a og b. Ikke kolonne c som kan være eks. et
> mega stort tekst felt eller en blob/clob.

<amerikans infomercial>That's good advice!</amerikansk infomercial>


Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkHvqx0ACgkQYu1fMmOQldVeSgCbBJwQ2U6i/uUJMnthO2mllseU
9o8An17NSdXoPr7oF5wmb0YRSk8PvOMG
=qQlw
-----END PGP SIGNATURE-----

---

Martin Christensen <martin.sand.christensen@gmail.com> writes:

> -- Deres metode
> PREPARE foo AS
> SELECT * FROM a, b
> WHERE
> a.fk = b.pk
> AND a.pk = $1
> AND b.pk = $2
>
> -- Min metode
> SELECT * FROM a, b
> WHERE
> a.fk = b.pk
> AND a.pk IN (a1, a2,...,am)
> AND b.pk IN (b1, b2,...,bn)
> LIMIT k

LIMIT uden at bruge ORDER BY er normalt tegn på at der er noget galt,
men det er du jo selv inde på.

Desuden er det såvidt jeg kan se ikke se samme forespørgelser idet
resultatet med (a.pk,b.pk) = (a1,b2) er med i dit resultat mens det
ikke er med i deres. Det er dog muligt at du har nogen bestemte
forhold i dine data som sikrer at det bliver det samme, men det er
ikke lige til at gennemskue.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kim Hansen <k-spam2003@oek.dk> writes:

> LIMIT uden at bruge ORDER BY er normalt tegn på at der er noget galt,
> men det er du jo selv inde på.

Yep. Da det er til brug i en søgemaskine, skal resultaterne i
princippet gerne ordnes efter en eller anden form for rang, og kun de
k mest interessante resultater ønskes, derfor brugen af LIMIT. Denne
rang kan så beregnes i DBMS'en vha. stored procedures, eller den kan,
som jeg gør nu, beregnes udenfor DBMS'en. Når man bruger sidste
løsning, må man forberede sig på enten at 1) udføre en masse
enkeltforespørgsler eller 2) risikere at hente flere data hjem, end
man har brug for. H,G&P gør det første, jeg gør det sidste. Jeg
overvejer nogle forskellige strategier til at gøre det ud for denne
brug af LIMIT.

> Desuden er det såvidt jeg kan se ikke se samme forespørgelser idet
> resultatet med (a.pk,b.pk) = (a1,b2) er med i dit resultat mens det
> ikke er med i deres. Det er dog muligt at du har nogen bestemte
> forhold i dine data som sikrer at det bliver det samme, men det er
> ikke lige til at gennemskue.

Der er ingen forhold i dataene som sådan, der sikrer, at resultaterne
bliver de samme i første omgang, men H,G&Ps strategi vil give samme
resultater som min fremgangsmåde, hvis man blot sætter k højt nok.


Tak for feedback'en. Er der nogen, der har kunnet sætte tal på
forskellen i performance?

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkHu/n8ACgkQYu1fMmOQldUR8wCgtM4HsMrKDqTfIXF5czuOLnYd
dvQAn2oP38aaJX5PGnFnPQ35ThX6o1Xr
=t8ju
-----END PGP SIGNATURE-----