Hey everybody..
I installed Pgsql 7.31(PgSQL731wina1.exe) on windows ( I already use
Apache+php4* on my XP) and..
I wanna use the phpPgAdmin tool on my system but I cant use it
Everytime I try to connect to database ı get the error (Login disallowed)
Can U tell me how to create and manage users o
On Wed, 4 Feb 2004, Iain wrote:
> If I understand checkpoints correctly, data that is already written to the
> WAL (and flushed to disk) is being written to the DB (flushing to disk).
> Meanwhile, other writer transactions are continuing to busily write to the
> WAL. In which case a disk bandwidth
I've seen similar behaviour with other disk-intensive apps, and in every
case it transpired that DMA was not enabled on the relevant disk/s -
something to check, certainly.
On Tue, 3 Feb 2004, Shane Wright wrote:
> Hi,
>
> I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux and I'm
> g
scott.marlowe wrote:
On Wed, 4 Feb 2004, Iain wrote:
If I understand checkpoints correctly, data that is already written to the
WAL (and flushed to disk) is being written to the DB (flushing to disk).
Meanwhile, other writer transactions are continuing to busily write to the
WAL. In which case a d
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
I have a simple query that scans each record, like this: select * from utente where
luogorilasciodoc='ciao'
The execution time BEFORE vacuum is: 1203ms The execution time AFTER vacuum is: 6656ms
!!!
What is going on? Thought that one vaccum the db to get better performance!
PostgreSQL Ver. 7.3.4 o
I have a simple query that scans each record, like this: select * from
utente where luogorilasciodoc='ciao'
The execution time BEFORE vacuum is: 1203ms The execution time AFTER
vacuum is: 6656ms !!!
What is going on? Thought that one vaccum the db to get better
performance!
PostgreSQL Ver. 7.3.4 o
On Wed, 4 Feb 2004, Edoardo Ceccarelli wrote:
> I have a simple query that scans each record, like this: select * from utente where
> luogorilasciodoc='ciao'
> The execution time BEFORE vacuum is: 1203ms The execution time AFTER vacuum is:
> 6656ms
> !!!
> What is going on? Thought that one vaccu
> -Messaggio originale-
> Da: scott.marlowe [mailto:[EMAIL PROTECTED]
> Inviato: mercoledì 4 febbraio 2004 22.45
> A: Edoardo Ceccarelli
> Cc: [EMAIL PROTECTED]
> Oggetto: Re: [ADMIN] slow seqscan after vacuum analize
>
> On Wed, 4 Feb 2004, Edoardo Ceccarelli wrote:
>
> > I have a simpl
On Thu, 5 Feb 2004, Edoardo Ceccarelli wrote:
> BEFORE (copy of the db without having run the vacuum):
>
> explain analyze SELECT * FROM utente where luogorilasciodoc='ciao';
> QUERY PLAN
>
> -
> --
> >
> >
> > Seq Scan on utente (cost=0.00..92174.50 rows=3 width=724) (actual
> > time=705.41..6458.19 rows=15 loops=1)
> >Filter: (luogorilasciodoc = 'ciao'::bpchar) Total
> runti
On Thu, 5 Feb 2004, Edoardo Ceccarelli wrote:
> Things are worst only for seqscan, when it uses indexscan timing is good.
It might just be that running VACUUM flushed the operating system's
buffer cache.
I always try running two or three EXPLAIN ANALYZE's in a row for the
same query. Usually, t
Yes, you are right but it wasn't the case this time, I have run the explain plenty of
times with same results. I think that the reason was that I made a simple VACUUM,
after a VACUUM FULL ANALYZE (1h!!) things are ok
Best Regards
Edoardo
> -Messaggio originale-
> Da: David F. Skoll [mail
> Yes, you are right but it wasn't the case this time, I have run the
explain plenty of
> times with same results. I think that the reason was that I made a simple
VACUUM,
> after a VACUUM FULL ANALYZE (1h!!) things are ok
It's reasonable to expect that a seq scan will perform faster after a ful
14 matches
Mail list logo
