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
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
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
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 machine):
Hi,
This a kind of newbie-question. I've been using Postgres for a long time in a low
transction environment - and it is great.
Now I've got an inquiry for using Postgresql in a heavy-load on-line system. This
system must handle something like 20 questions per sec with a response time at 1/10
I just restored a database running on a solaris box to a linux box
and queries take forever to execute. The linux box is faster and has
twice the memory allocated to postgresql, is there anything obvious that
I should look at? It is using a journal file system.
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It appears that the optimizer only uses indexes for = clause?
The optimizer will used indexes for LIKE clauses, so long as the
clause is a prefix search, eg:
SELECT * FROM test WHERE a LIKE 'prf%';
Doesn't this still depend on your locale?
Hi, This a
kind of newbie-question. I've been using Postgres for a long time in a low
transction environment - and it is great. Now I've got an inquiry for
using Postgresql in a heavy-load on-line system. This system must handle
something like 20 questions per sec with a response time at
On Thu, 2003-12-18 at 12:04, Conny Thimren wrote:
Hi,
This a kind of newbie-question. I've been using Postgres for a long time in a low
transction environment - and it is great.
Now I've got an inquiry for using Postgresql in a heavy-load on-line system. This
system must handle something
Michael Guerin [EMAIL PROTECTED] writes:
I just restored a database running on a solaris box to a linux box
and queries take forever to execute.
Did you remember to run ANALYZE? Have you applied the same
configuration settings that you were using before?
regards,
On Thu, 18 Dec 2003, Conny Thimren wrote:
Hi,
This a kind of newbie-question. I've been using Postgres for a long time in a low
transction environment - and it is great.
Now I've got an inquiry for using Postgresql in a heavy-load on-line system. This
system must handle something like 20
Ideally that path isn't taken very often. But I'm currently having a
discussion off-list with a CMU student who seems to be seeing a case
where it happens a lot. (She reports that both WALWriteLock and
WALInsertLock are causes of a lot of process blockages, which seems to
mean that a lot
12 matches
Mail list logo
