Zu lange Abfrage?

Danke für die schnelle antwort!
schau mir das direkt mal an

Gruß

also z.b.

SELECT blah FROM tab WHERE id IN (1, 2, 3, 5, …);

cu tb.

Verdammt, leider ist da das selbe Phänomen.
Ab einer bestimmten anzahl an IDs irgnoriert er das :frowning:

hast du die INs für das IN() in einer anderen Tabelle oder gibst du die auch per Hand an?

An sich schon komisch, aber kannst du einmal etwas ausführen, was genau du da filtern möchtest?

Ne, in einer Tabelle habe ich es nicht.
Ist im Prinzip das Ergebnis von einem Anderen Script.
Als vielseitige “Schnittstelle” sozusagen habe ich die Kette der jeweiligen IDs.
Mit diesen IDs, die ich willkürlich irgendwie ablegen/übertragen kann (Als Text Datei, oder als Link oder einfach grade mal in der Ablage…), möchte ich das rückwärts wieder ausgelesen haben.

Als beispiel:

10032000,10005400,10011500,10011510,10011520,10012100,10012400,10012500,10012600,10012700,10015300,10016500,
10016600,10017800,10017810,10017820,10018300,10018400,10022500,10022600,10022700,10022800,10029600,10029700,
10031800,10032500,10032700,10032710,10032720,10032800,10033300,10033310,10033320,10033500,10033600,10034200,
10034210,10034220,10035600,10035610,10035620,10037100,10037900,10038000,10039200,10040000,10040010,10040020,
10041500,10042800,10043200,10046700,10046710,10046720,10047500,10049000,10050800,10054000,10063200,10063400,
10063700,10063800,10064600,10064700,10064800,10065200,10065400,10065500,10065600,10065610,10065620,10065900,
10066000,10066100,10066200,10066210,10066220,10067300,10067500,10067800,10068000,10068100,10068200,10068210,
10068220,10068300,10068310,10068320,10068500,10068510,10068520,10068600,10068610,10068620,10068630,10068700,
10068800,10068900,10069000,10069100,10069200,10069400,10069700,10069800,10070200,10070210,10070220,10070400,
10070510,10070520,10070900,10070910,10070920,10071020,10071100,10071320,10072400,10072410,10072420,10072600,
10073900,10074000,10074100,10074200,10074210,10074220,10074300,10074310,10074320,10074400,10074500,10074700,
10074800,10074810,10074820,10075700,10075900,10076000,10076100,10076200,10076300,10076400,10076500,10076600,
10077400,10079500,10079510,10081000,10081100,10081900,10081910,10081920,10082300,10083000,10083010,10083020,
10083100,10083200,10083300,10083400,10084000,10084100,10084200,10084400,10084600,10084800,10085200,10086500,
10086600,10086700,10089800,10089900,10090000,10090100,10090200,10090300,10090600,10090700,10090800,10090900,
10091900,10092500,10093500,10094910,10094920,10096000,10096010,10096020,10096100,10096110,10096120,10096500,
10096800,10096900,10097000,10097100,10097200,10097300,10097400,10097500,10097700,10097710,10097720,10097800,
10097900,10097910,10098000,10098100,10098200,10098300,10098400,10098500,10098600,10098610,10098620,10099300,
10099400,10099600,10099700,10099800,10099900,10100000,10100100,10100110,10100120,10100200,10101000,10101010,
10101020,10101100,10102200,10102300,10102500,10102900,10103200,10103210,10103220,10103900,10104000,10104100,
10104200,10104700,10104800,10107200,10107300,10107400,10110600,10110700,10110800,10110900,10111000,10118100,
10118110,10121600,10127200,10129400,10129410,10129420,10129500,10129510,10129520,10131900,10131910,10131920,
55001000,55001300,55001900,55002000,55002500,55005900,55006400,55007400,55009300,55009310,55009800

(->Ich habe paar Enterzeichen hinzugefügt, damit das hier nicht das board so hässlich verzieht)

Das wird schließlich zu:

SELECT * FROM ware WHERE art='' AND id IN('10131900','10131910'...) ORDER BY bezeichnung,gruppe ASC

Natürlich gibt es da improvisationen, aber das muss auf jeden fall auch so gehen.

Gruß

buuh, da scheint es doch irgendwie ein limit zu geben… ich erinnere mich an oracle das hier bei einem IN max 256 elemente vorhanden sein durften. allerdings konnte man dann ein

field IN (…) or field IN (…)

machen und damit das 256 limit unschön umgehen. eine andere selektierungsmöglichkeit umd hier alle gewünschten daten zu bekommen hast du nicht?

cu tb.

Hast du die Möglichkeit, beide Queries zusammenzulegen, so das du nicht erst nach extern die IDs schieben musst und mit diesen dann einen komplizierten Query zusammenbaust?

Hallo Sy-,

warum machst Du es so kompliziert?

Lese mit Copy die Id’s in eine eigene Tabelle und verbinde beide Tabellen in der SELECT-Anweisung mittels eines JOIN. Ob Du dann 20, 200 oder 2000 ID’s eingelesen hast, es funktioniert immer!



mfg

fristo

Btw, mittlerweile weiss ich auch, warum dein Query abbricht. Die Größe der OR oder IN() Abfragen wird durch die verfügbare Stacktiefe begrenzt.

hi,

kann ich die anpassen? ggf. durch compiler parameter? bin jetzt zu faul zu suchen und readmes/dokus zu lesen :wink:

cu tb.

Wie wäre es, das Betriebssystem zu fragen, wie groß der Stack ist? :wink:

hi,

naja bei java kann ich das ja beim kompilieren mit übergeben :wink:

cu tb

Ich hätte jetzt eher auf so etwas getippt:

ads@iridium:/home/ads > ulimit -a

stack size (kbytes, -s) 65536


Aber müsste man ausprobieren.

Also grade mal für eine Abfrage eine IN bzw OR Query generieren zu lassen finde ich unkomplizierter, als die Daten in eine spezielle Tabelle zu schreiben und dann durch Join das ganze abzurufen :wink:
Aber du hast recht, das wird auf jeden fall gehen.
Muss ja aber auch so gehen.

Ich habe mal in der postgresql.conf geschaut und schätze, dass es die eigenschaft “max_stack_depth”
Korrigiert mich wenn es nicht so ist, denn bislang hat es noch keine Auswirkungen bei mit gehabt (Ja ich habe pg neu gestartet :wink: )

Gruß

max_stack_depth kann auch nicht größer werden als der Stack ist, den dir das Betriebssystem zur Verfügung stellt. Allerdings, wie gesagt, das ganze müsste ich selber auch erst einmal probieren, auf das Problem bin ich noch nie gestossen.

hi,

der stack ist vom kernel abhängig. allerdings liest der postgresql server die werte aus und deswegen musst du das setzen weil das nicht immer geprüft wird.

näheres hier: http://www.postgresql.org/docs/8.1/interactive/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY

cu tb.

Hallo,

kompliziert, kompliziert, kompliziert, …

TRUNCATE TABLE          TABLE_ID;

COPY                    *
FROM                    TABLE_ID.txt;

SELECT                  * 
FROM                    ware 
INNER JOIN              TABLE_ID
USING                   (
                        id
                        )
WHERE                   art='' 
ORDER BY                bezeichnung ASC;

:lol: :lol: :lol: Ich sage es ja immer, ein neues Betriebssytem zu entwickeln ist einfacher als 2 Tabellen mit einen JOIN zu verbinden! :lol: :lol: :lol:



mfg

fristo

Ging nicht darum, dass es zu kompliziert ist, aber komplizierter bzw aufwendiger als nur 1 Zeile.
Dieses Thread hier ist ja im Sinne von speziell dieser Möglichkeit ohne Improvisation.

Aber schließlich hast du wohl recht, dass jeder andere weg bei PG simpler ist als es passend für diese Methode zu konfigurieren.

Komisch ist, dass MySQL mit sowas garkeine Probleme zeigt.
Hier ist es vom Stack abhängig… Wohl aus Leistungsgründen?

Das wird bei Mysql ebenfalls vom Stack abhängig sein, irgendwo muss der Parser ja die Informationen zwischenlagern, wenn er die Anfrage zusammenbaut.

Eigentlich hat fristo Recht, es ist vor allem performanter, die Geschichte innerhalb der DB zu erledigen, als wenn man die Daten erst aus der DB per Netzwerk (ja, localhost ist auch ein Netzwerk) überträgt, dann zusammensortiert und dann wieder einfügt. Vor allem kann die Datenbank unter Umständen, wenn man das alles in einem Query löst, von vorneherein bestimmte Ergebnisse in der Zieltabelle (Stichwort: Index) ausschliessen und so die Abfragezeit noch einmal verringern und die Performance verbessern.

Das gehört dann in die Ecke Feintuning :wink: