@JajkoJajkoJajkoJajko: Nigdy, ale to NIGDY nie składaj zapytań SQL poprzez łączenie stringów, tak jak robisz to teraz. To aż się prosi o SQL Injection

@JajkoJajkoJajkoJajko: psycopg (jak chyba każda sensowna biblioteka bazodanowa) obsługuje prepared statements, więc skorzystaj z tego, zamiast łączyć stringi

@danoxide: afaik najmniejsza jednostka locka jest wiersz.

The SQL I Love <3. Efficient pagination of a table with 100M records #sql #postgresql

http://allyouneedisbackend.com/blog/2017/09/24/the-sql-i-love-part-1-scanning-large-table/

@interface: Nic nowego, w tym temacie standardowym linkiem jest:
http://use-the-index-luke.com/sql/partial-results/fetch-next-page

@czyzyk14: jeśli nie potrafisz sam ogarnąć tak prostej rzeczy to raczej nie masz sie pchać do tej roboty

@JajkoJajkoJajkoJajko: pewnie szukasz czegoś takiego jak "złożony klucz główny", który zakładasz na dwóch lub więcej kolumnach

@JajkoJajkoJajkoJajko: jak jest klucz główny, to musi być unikatowy, wiec kluczem głównym powinna być kombinacja tych kluczy, natomiast 2 pozostałe zrób jako indeksy (jeśli chcesz po nich szybko wyszukiwać)

@JajkoJajkoJajkoJajko: przede wszystkim porządek w danych. Jeśli nie ma referencji to teoretycznie można zrobić bajzel aplikacją.
Klucze obce to też przymus stawiania unique indexów które przyśpieszają złączenia po tych kolumnach.

Czy i w jaki sposób klucze obce ułatwiają łączenie tabel?

@JajkoJajkoJajkoJajko: Nie do tego służą. Podstawową funkcją klucza obcego jest zapewnienie spójności danych.

@kleksiq: Może nie akurat dla (info|m)medica i nie hyper-v, ale mam doświadczenie z postgresami, wirtualizacjami, serwerami fizycznymi, macierzami etc...

(jednordzeniowy celeron, 256MB RAM).

@tinka69: Bez grafiki to cokolwiek, z grafiką to bym celował w TinyCore ale nie wiem jak z używaniem tego na dłuższą metę.

nie wiem jak z używaniem tego na dłuższą metę.

@a231: Całkiem ok ( ͡° ͜ʖ ͡°)

@indywidualny a nie lepiej pozwolić żeby zwróciło błąd i wtedy w kodzie sprawdzić który to constraint?

@Romantyczny_widelec poczytaj o transakcyjności. W MySQL kuleje. Często bywa to problemem. To taki pierwszy z brzegu problem z nim. Z drugiej strony MySQL ma wiele zalet i ciężko z niego zrezygnować tylko ze względu na wspomnianą przeze mnie transakcyjność. Czekam na wady MySQL/Postgresa kolegów :)
P.S. expert ze mnie żaden :)

@Romantyczny_widelec: Z doświadczenia trzy różnice które mogą najbardziej rzutować na wybór rozwiązania:

1. PostgreSQL jest wydajniejszy przy skomplikowanych obliczeniowo zapytaniach, ale Query Cache MySQL potrafi całkiem nieźle kompensować jego niedostatki na tym polu. Jeżeli zapytania są bardzo często powtarzalne na tym samym zestawie danych, a ich rezultaty na tyle małe by w query cache się mieściły to fakt że pierwsze wykonanie zapytania wykonuje się dłużej przestaje mieć znaczenie ponieważ kolejnePokaż całość

https://www.youtube.com/channel/UCe6nK69Yc1zna7QSJEfA9pw/videos?sub_confirmation=1

@imlmpe: karniak za link do subskrypcji

@imlmpe: tyś jest unknow? No to ci powiem, że z twoimi kursami szkoliłem się w MySQL-u :) . Dykcja początkowo trochę denerwowała, ale później to stał się z tego taki twój znak rozpoznawczy :)

@chapak: pg-promise ;) uzywałem wszystkich powyższych ale w moim przypadku najlepiej sprawdził sie pg-promise po prostu

@chapak: Jestem zmuszony używać sequelize… rak niemiłosierny. Dziesiątki zmarnowanych godzin na debugowaniu dziwnych problemów, jakieś nieudokumentowane opcje, które jak masz fart, to znajdziesz w issues na githubie…

@RicoElectrico: LIKE używa operatora ~~, jest to inny operator niż =. Jeśli włączysz btreegist to możesz mieć index gist który na jednym poziomie będzie miał trigramy a na drugim = się dla textu (gisttext_ops) ale razem się tego skombinować nie da. Tyle od strony technicznej, czemu nie zaimplementowali = się dla textu musisz się pytać autorów. Jak ci się nudzi to możesz zaimplementować klasę operatorów która łączy obiePokaż całość

@SuperStefan: Odrzuć pary, w których różnica jest ujemna

@SuperStefan: może
select a.data - b.data
from users as a, users as b
where a.id > b.id