[Python] Applicazione WEB con Python e Postgresql

[Marco De Paoli]

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.porcari a softwell.it> ha scritto:
>
>> Il giorno 24/set/2014, alle ore 16:15, Giovanni Porcari <giovanni.porcari a softwell.it> ha scritto:
>>
>>>
>>> Il giorno 24/set/2014, alle ore 15:50, Marco De Paoli <depaolim a gmail.com> ha scritto:
>>>
>>> Il 24 settembre 2014 14:01, Marco De Paoli <depaolim a gmail.com> ha scritto:
>>>> Il 24 settembre 2014 11:03, Giovanni Porcari
>>>> <giovanni.porcari a 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