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
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, 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
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
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
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.
--
> 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
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
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
13 matches
Mail list logo
