ciao Giovanni, grazie della pazienza in effetti temo di essere finito abbondantemente OT (ormai siamo al "puro SQL", anzi al "puro postgres"...)
Il 24 settembre 2014 16:33, Giovanni Porcari <giovanni.porc...@softwell.it> ha scritto: > >> Il giorno 24/set/2014, alle ore 16:15, Giovanni Porcari >> <giovanni.porc...@softwell.it> ha scritto: >> >>> >>> Il giorno 24/set/2014, alle ore 15:50, Marco De Paoli <depao...@gmail.com> >>> ha scritto: >>> >>> Il 24 settembre 2014 14:01, Marco De Paoli <depao...@gmail.com> ha scritto: >>>> Il 24 settembre 2014 11:03, Giovanni Porcari >>>> <giovanni.porc...@softwell.it> ha scritto: >>>>> >>>>> >>>>> Cioè tu dici che se io cerco su migliaia di milioni di record >>>>> quello con primary key = 'R2L_cGpqOoOELD1saCR2mg' una macchina >>>>> moderna ci mette 2000 nanosecondi di più che a cercare >>>>> con pkey=3456123456 ? >>>> >>>> volendo fare una prova quick&dirty su postgres con 40 ml di record... >>>> https://gist.github.com/depaolim/879a64256d146ddb0589 >>> >>> ok, i 40 milioni di record vi avevano spaventato >>> ora l'ho modificato per funzionare con 1 milione di record >>> https://gist.github.com/depaolim/879a64256d146ddb0589 >>> >>> ... ma i risultati continuano ad essere sorprendenti >>> >>> per voi no? >>> >> >> Per uno pigro ma curioso come me quali sono i risultati ? risposta breve: al momento non li ho :-( >> >> Grazie :) risposta lunga: sulla carta sottoscrivevo anche io la tesi "integer batte uuid e festa finita" ecco perchè ho scritto il mini test: per sfizio di vedere di quanto l'uno batteva l'altro e mi sono ritrovato che ... gli uuid battevano gli integer !!! ho concluso però che il mio problema è che al momento ho sotto mano solo server postgres con "buffer cache" "ballerine" (sono usati anche per altro e non posso maneggiarli/riavviarli quando mi va) per cui direi che al momento il tutto è abbastanza falsato riprovo prossimamente in condizioni più pulite > > A meno che tu non abbia verificato che riempire un indice con valori ordinati > e dannatamente più lento che non riempirlo con valori 'casuali'. Questo > perchè l'albero deve essere ribilanciato molto più spesso. beh, nel mio mini test ho ovviato a questo problema costruendo la chiave primaria *dopo* aver inserito i valori ma si tratta appunto di un test di "laboratorio" > In effetti anche questa è una ragione che mi aveva fatto preferire degli id > non sequenziali... in realtà te la cavi con un periodico rebuild degli indici (reindex su postgres) ciao a tutti e scusate l'OT, Marco _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python