LIKE
без заместващ знак е еквивалентен на =
. Ако приемем, че всъщност сте имали предвид name = 'text'
.
Индекси са ключът към производителността.
Тестова настройка
CREATE TABLE image (
image_id serial PRIMARY KEY
, group_id int NOT NULL
, name text NOT NULL
);
В идеалния случай създавате два индекса (в допълнение към първичния ключ):
CREATE INDEX image_name_grp_idx ON image (name, group_id);
CREATE INDEX image_grp_idx ON image (group_id);
Вторият може не е необходимо, в зависимост от разпространението на данни и други подробности. Обяснение тук:
- Съставният индекс добър ли е и за заявки в първото поле?
Запитване
Това трябва да е най-бързият възможен запитване за вашия случай:
SELECT * FROM image WHERE name = 'name105' AND group_id = 10
UNION ALL
SELECT * FROM image WHERE name = 'name105'
UNION ALL
SELECT * FROM image WHERE group_id = 10
LIMIT 1;
SQL Fiddle.
LIMIT
клаузата се прилага за цялата заявка. Postgres е достатъчно уменза да не се изпълнява по-късни части на UNION ALL
веднага щом намери достатъчно редове, за да удовлетвори LIMIT
. Следователно за мач в първия SELECT
на заявката, изходът на EXPLAIN ANALYZE
изглежда така (превъртете надясно! ):
Limit (cost=0.00..0.86 rows=1 width=40) (actual time=0.045..0.046 rows=1 loops=1) Buffers: local hit=4 -> Result (cost=0.00..866.59 rows=1002 width=40) (actual time=0.042..0.042 rows=1 loops=1) Buffers: local hit=4 -> Append (cost=0.00..866.59 rows=1002 width=40) (actual time=0.039..0.039 rows=1 loops=1) Buffers: local hit=4 -> Index Scan using image_name_grp_idx on image (cost=0.00..3.76 rows=2 width=40) (actual time=0.035..0.035 rows=1 loops=1) Index Cond: ((name = 'name105'::text) AND (group_id = 10)) Buffers: local hit=4 -> Index Scan using image_name_grp_idx on image (cost=0.00..406.36 rows=500 width=40) (never executed) Index Cond: (name = 'name105'::text) -> Index Scan using image_grp_idx on image (cost=0.00..406.36 rows=500 width=40) (never executed) Index Cond: (group_id = 10) Total runtime: 0.087 ms
Удебелен акцент мое.
Не добавете ORDER BY
клаузата , това би анулирало ефекта. Тогава Postgres ще трябва да разгледа всички редове, преди да върне горния ред.
Последни въпроси
Има ли общо решение за това?
Товае общото решение. Добавете толкова SELECT
изявления, както искате.
Разбира се, би било полезно, когато резултатът от търсенето е сортиран по неговата уместност.
В резултата има само един ред с LIMIT 1
. Вид сортиране на кухини.