Guten Tag Ryszard Lach,
Am Montag, 22. Dezember 2003 um 11:39 schrieben Sie:
RL> Hi.
RL> I have a table with 24k records and btree index on column 'id'. Is this
RL> normal, that 'select max(id)' or 'select count(id)' causes a sequential
RL> scan? It takes over 24 seconds (on a pretty fast machin
Dnia 2003-12-22 11:39, Użytkownik Ryszard Lach napisał:
Hi.
I have a table with 24k records and btree index on column 'id'. Is this
normal, that 'select max(id)' or 'select count(id)' causes a sequential
scan? It takes over 24 seconds (on a pretty fast machine):
'select count(id)'
Yes, this is no
Hello
It is normal behavior PostgreSQL. Use
SELECT id FROM tabulka ORDER BY id DESC LIMIT 1;
regards
Pavel
On Mon, 22 Dec 2003, Ryszard Lach wrote:
> Hi.
>
> I have a table with 24k records and btree index on column 'id'. Is this
> normal, that 'select max(id)' or 'select count(id)' causes a
I have a table with 24k records and btree index on column 'id'. Is this
normal, that 'select max(id)' or 'select count(id)' causes a sequential
scan? It takes over 24 seconds (on a pretty fast machine):
=> explain ANALYZE select max(id) from ogloszenia;
Yes, it is. It is a known issue with Postgr
Hi.
I have a table with 24k records and btree index on column 'id'. Is this
normal, that 'select max(id)' or 'select count(id)' causes a sequential
scan? It takes over 24 seconds (on a pretty fast machine):
=> explain ANALYZE select max(id) from ogloszenia;
QUERY PLAN
