[100x]

Mam tabele x(id bigserial primary key, productnumber text)
Reszta kolumn nie istotna, bo nie używana w warunkach.
50 milionów unikalnych rekordów z perspektywą na 2 krotny wzrost w ciągu kilku lat, btree index na productnumber

proste pytanie do bazy
select id from x where product_number = $1 order by id dead limit 1

1. W jednym miejscu ktoś przeważnie będzie pytał o numery, które nie istnieją, ale czasem powiedzmy co 10 numer będzie istniał.

2. W drugim miejscu ktoś będzie pytał tylko o istniejące numery w bazie.

W pierwszym przypadku takie pytanie trwa za długo(co najmniej kilka sekund) gdy nie znajdzie rekordu a gdy znajdzie to dużo szybciej.

Jak podejść do tego problemu żeby mieć czas poniżej sekundy gdy szukam nieustającego jeszcze numeru? Postgresql musi i tak skanować całą tabelę.

#programista15k #postgresql #sql

[afuera]

@100x: explain pokaż

[JaTobieTyMi]

@100x ja bym zrobił partial index czyli WHERE product number IS not null

Poprawi performance 1 przypadku i nie zmieni 2

[100x]

@afuera:

nie na tej samej bazie ale problem taki sam

CREATE TABLE public.x (
	id bigserial

[dejvo]

@100x: ale z tego wynika, że korzysta on z indexu PK z tabeli x. Nazwij jakos ten twoj indeks np. xbtree
CREATE INDEX xbtree ON public.x USING btree (product_number);
i odpal explain jeszcze raz.
Może też jeszcze być tak, że ORDER BY wymusza indeks z PK. Skoro wyciagasz jeden wiersz, to raczej tego ORDER BY nie potrzebujesz.

[100x]

@dejvo:

oprócz twojego pomysłu sprawdziłem jeszcze inne, które przyszły mi do głowy,

Może też jeszcze być tak, że ORDER BY wymusza indeks z PK. Skoro wyciagasz jeden wiersz, to raczej tego ORDER BY nie potrzebujesz.

potem sprawdzę czy w innych bazach jest

[dejvo]

@100x: dodatkowo jeśli chesz tylko informacji czy wartosc (nie) istnieje, to można używać (NOT) EXISTS
https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-exists/

[100x]

@dejvo: na tym się skończy, że będę musiał przed właściwym pytaniem dać warunek sprawdzający czy rekord istnieje,

szkoda, że postgresql nie radzi sobie z tym automatycznie

[Arogancky]

@100x: plz, na mssql mam 7 milionów i jak liczę hasze per wiersz to serwer robi fikołka. A jak robię merge po haszu to jeszcze się zesrywa podczas fikołka