Van egy kis webes alkalmazasom ami postgresbol dolgozik. Nem vagyok elegedett a sebessegevel, szeretnek gyorsitani rajta. Most valami ilyesmi van benne amit szeretnel leroviditeni:
select * from table where....;
ami vegigturja az egesz DB-t, de aztan vegul csak az elso 100 (vagy valahany) talalat jelenik meg a bongeszoben. Szoval eleg lenne valami ilyesmi is:
select * from table where.... limit 100;
Ez sokat segit, viszont igy nem tudom kiirni, hogy a teljes adatbazisban hany talalat van! Pedig azt is szeretnem megjeleniteni (most meg is jelenitem). Persze megtehetnem, hogy ezutan meg futtatok egy "select count(*)..."-ot, de akkor nem nyertem semmit, hiszen at kell turni az egesz DB-t (reszben ujra).
Ket megoldas jutott az eszembe... vagyis egyik se megoldas meg, mert nem tudom, hogy lehetne oket megcsinalni, ha egyaltalan...
a) a PHP
pg_queryfuggvenye olyan, hogy nem ter vissza ameg a teljes select le nem futott. Nem lehetne valahogy a mar kikeresett rekordokat visszakapni (mondjuk a sorrend nem szamit) mikozben a select meg fut? Ettol a DB keres ugyan nem lenne gyorsabb, de a weben hamarabb latszana az eredmeny.
b) a
...limit 100-as megoldas is jo lenne onmagaban, ha lehetne tudni, hogy a limit 100 elereseig a tablanak mekkora reszet kellett atnezni es ebbol megbecsulni, hogy az egesz DB-ben hany talalat lett volna (pontossag nem fontos). Vagyis ha az "alma"-ra keresek, amire a DB elso 2%-anak atnyalazasabol osszejon a 100 talalt, ott a limit leall, en meg ezt az eredmenyt felszorozva irnam ki, hogy hany alma van a teljes DB-ben. Le lehet valahogy kerdezni, hogy hol jart a select mikor a limit-hez ert? mOndjuk mi az utolso rekord sorszama?
- 1611 megtekintés
Hozzászólások
javaslom , hogy a keresési mezőkre indexeld le a tábládat, illetve a select count(*) helyett SELECT Count(indexeltmező) -t használj. Ez már alapvetően sokat fog gyorsítani az oldaladon.
- A hozzászóláshoz be kell jelentkezni
+1
indexek, ügyes count(), limit használata, és új életre kel a webalkalmazás :)
- A hozzászóláshoz be kell jelentkezni
-1
indexek vannak (amire lehet), count(*)-ot meg egyaltalan nem hasznalok. "select *..." szeru dolgok vannak amibol a php tudja azt is hogy hany rekordot kapott, szoval nem kell a count(*) ha mar ugyis megvolt a lekerdezes.
a limit meg jo lenne... de pont az a baj, hogy azt nem tudom hasznalni... (lasd fonn)
- A hozzászóláshoz be kell jelentkezni
Én így gondolom:
$res = pg_query("SELECT * FROM tabla WHERE $where LIMIT 100");
$num = pg_num_rows($res);
if($num == 100) {
$resn = pg_query('SELECT COUNT(kulcs) AS num FROM tabla WHERE $where');
$obj = pg_fetch_object($resn);
$num = $obj->num;
}
- A hozzászóláshoz be kell jelentkezni
Na, akkor ez olyan mint a b) "megoldasomban", csak en ezt a masodik select-et szeretnem meguszni.
Egyebkent kozben probalgattam es semmi kulonbseget nem latok (idoben) a count(*) es a count(kulcsos_mezo) kozott...
- A hozzászóláshoz be kell jelentkezni
A 2 select még mindig sokkal gyorsabb, mint a ha limit nélkül hívod az elsőt, és van 10000+ rekordod.
- A hozzászóláshoz be kell jelentkezni
tárolt függvény kell és trigger (insert, delete), nincs semmi trükk ebben, van egy táblád amiben a row countokat tartod nyilván
- A hozzászóláshoz be kell jelentkezni
+1
indexet tegyel a keresett mezore.
Lehet hash is ha =, vagy btree ha < >.
--
BSD Support Service
- A hozzászóláshoz be kell jelentkezni
Mennyire változik a lekérdezés? mert ha nem nagyon, akkor az új sor beillesztésekor elmented egy külön táblába a sorok számát, s akkor csak azt kell lekérdezned, nem az egész db-t. Ez mondjuk nyilván limitált számú típuslekérdezésig jó megoldás.
- A hozzászóláshoz be kell jelentkezni
ilyen adatot érdemes inkább memcache-be rakni
- A hozzászóláshoz be kell jelentkezni
A lekerdezes egyreszt nagyon valtozik, masreszt a DB-t read only modban erem el (bar ezen lehet valtoztatni, de az egy kis visszalepes a biztonsag teren).
- A hozzászóláshoz be kell jelentkezni
Az indexekrol (ha mar felvetodott) meg egy kicsit:
Az (is) a baj, hogy az egyik mezon szabad szavas kereses van, amin nemigen hasznal az index. Ha ez nem lenne, akkor -gondolom- nagysagrendeket is gyorsulhatna a kereses.
(Es mielott ez is felvetodne: a select where-je ugy van osszerakva, hogy a like "%alma%" tipusu feltetel az utolso legyen, ugyhogy a jol indexelheto mezok mar szurnek korabban.)
- A hozzászóláshoz be kell jelentkezni
SQL_CALC_FOUND_ROWS egy erv h valts MySql -re :)
Bocs, de annyira idekivankozott!
Otletem csak annyi lenne, hogy esetleg valami tarolt eljaras v. fuggveny csinalna a lekerdezest limit nelkul. Az osszeszamolna a talalatok szamat valtozoba mentene, majd visszaadna a limitalt result set -et. Egy ujabb lekressel meg lekerned a valtozo erteket. Ebben az lenne a jo, h egyfelol nem kell ketszer lefutatni ugyan azt a kerest 8limittel es nelkule), masfelol nem kell atpaszirozni a php -nak a full result setet es aztan ott buveszkedni vele, igy az egesz db oldalon futna ezert viszonylag gyors lenne. Vagy ez hulyeseg? :D
- A hozzászóláshoz be kell jelentkezni
HUUUUUUUUUUUUUUU. Gondolom azért írsz ilyet mert keveset aludtál.
1) SELECT COUNT(mezo) FROM tabla WHERE ...;
2) SELECT mezo1, mezo2 FROM table WHERE ... LIMIT N OFFSET N;
- A hozzászóláshoz be kell jelentkezni
A fenti verzió gyorsabb. Sokkal gyorsabb. Majdnem dupla olyan gyors.
- A hozzászóláshoz be kell jelentkezni
en nulladik pontnak azert odatennem, hogy jelentkezzen, aki ismeri ennek a PgSQL-es verziojat -- ha van! en is kerestem mar egyebkent, de nem jelent semmit, hogy nem talaltam :)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ez nem ertem mire lenne nekem jo.
- A hozzászóláshoz be kell jelentkezni
Na, ez mar jobbnak tunik. Meg sose cursor-oztam... de minthe ez pont arra lenne jo ami nekem kell.
- A hozzászóláshoz be kell jelentkezni