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 Postgr
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
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
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
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
s
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
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/1
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 somet
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 li
> 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 l
13 matches
Mail list logo
