I think it is definitely necessary from an administration point of view - as an
administrator, I want to know:
1) Are there any stats (at all) in a schema
2) Are there any stats on the table that slow_query_foo is targeting
3) If I have stats, how recent are they
4) Could it be that there are a l
"Matthew T. O'Connor" writes:
> It is fairly easy to implement, however it has been discussed before and
> decided that it wasn't necessary. What the system cares about is how
> long it's been since the last vacuum in terms of XIDs not time.
I think Alvaro is intending to do the latter (store
Mikael Carneholm wrote:
This is where a "last_vacuumed" (and "last_analyzed") column in
pg_statistic(?) would come in handy. Each time vacuum or analyze has
finished, update the row for the specific table that was
vacuumed/analyzed with a timestamp in the last_vacuumed/last_analyzed
column. No mo
This is where a "last_vacuumed" (and "last_analyzed") column in
pg_statistic(?) would come in handy. Each time vacuum or analyze has
finished, update the row for the specific table that was
vacuumed/analyzed with a timestamp in the last_vacuumed/last_analyzed
column. No more guessing "maybe I haven
Hello to all on the list.
I have developed a product that sits between the database and an
application that handles the storage of large binary data.
The system is fast, but I'm feeling bad as to think that I have
completely reinvented the weel on this case.
You see, the engine does just stores
On 27.03.2006, at 21:20 Uhr, Brendan Duddridge wrote:
Does that mean that even though autovacuum is turned on, you still
should do a regular vacuum analyze periodically?
It seems that there are situations where autovacuum does not a really
good job.
However, in our application I have made
Brendan Duddridge wrote:
> Does that mean that even though autovacuum is turned on, you still
> should do a regular vacuum analyze periodically?
No, it probably means you have set FSM settings too low, or not tuned
the autovacuum parameters to your specific situation.
A bug in the autovacuum da
Gábriel Ákos wrote:
Luke Lonergan wrote:
Gabriel,
On 3/27/06 10:05 AM, "Gábriel Ákos" <[EMAIL PROTECTED]> wrote:
That gave me an idea. I thought that autovacuum is doing it right, but I
issued a vacuum full analyze verbose , and it worked all the day.
After that I've tweaked memory settings a
Does that mean that even though autovacuum is turned on, you still
should do a regular vacuum analyze periodically?
Thanks,
Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED]
ClickSpace Interactive Inc.
Suite L1
[PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.0.1]
I have a simple join on two tables that takes way too long. Can you help
me understand what's wrong? There are indexes defined on the relevant columns.
I just did a fresh vacuum --full --analyze on the two tables.
Is there s
Luke Lonergan wrote:
Gabriel,
On 3/27/06 10:05 AM, "Gábriel Ákos" <[EMAIL PROTECTED]> wrote:
That gave me an idea. I thought that autovacuum is doing it right, but I
issued a vacuum full analyze verbose , and it worked all the day.
After that I've tweaked memory settings a bit too (more fsm_pa
Gabriel,
On 3/27/06 10:05 AM, "Gábriel Ákos" <[EMAIL PROTECTED]> wrote:
> That gave me an idea. I thought that autovacuum is doing it right, but I
> issued a vacuum full analyze verbose , and it worked all the day.
> After that I've tweaked memory settings a bit too (more fsm_pages)
Oops! I repl
Jim C. Nasby wrote:
But in this case, I'd bet money that if it's taking 4 minutes something
else is wrong. Have you been vacuuming that table frequently enough?
That gave me an idea. I thought that autovacuum is doing it right, but I
issued a vacuum full analyze verbose , and it worked all the
Luke Lonergan wrote:
To test your disk speed, use the following commands and report the times
here:
time bash -c "dd if=/dev/zero of=bigfile bs=8k count=50 && sync"
[EMAIL PROTECTED]:/fast # time bash -c "dd if=/dev/zero of=bigfile bs=8k
count=50 && sync"
50+0 records in
5
Gabriel,
On 3/27/06 5:34 AM, "Gábriel Ákos" <[EMAIL PROTECTED]> wrote:
> Question: I have a table with 2.5M rows. count(*) on this table is
> running 4 minutes long. (dual opteron, 4gig ram, db on 4 disk raid10
> array (sata, not scsi)) Is this normal? How could I make it run faster?
> Maybe make
On Mon, Mar 27, 2006 at 04:25:25PM +0200, luchot wrote:
> Hello everybody ,
> I use PostgreSQL 8.1.3 on a bi-processor Xeon and I would know how to do to
> enable a parallelism for
> the execution of queries. Indeed , when I analyse the use of the cpus during
> a query the result is that for
>
Hello everybody ,
I use PostgreSQL 8.1.3 on a bi-processor Xeon and I would know how to do to enable a parallelism for
the execution of queries. Indeed , when I analyse the use of the cpus during a query the result is that for
some minutes a cpu is used while the other not and after it is the co
On Mon, Mar 27, 2006 at 03:34:32PM +0200, G?briel ?kos wrote:
> Hi,
>
> I guess this is an age-old 100times answered question, but I didn't find
> the answer to it yet (neither in the FAQ nor in the mailing list archives).
>
> Question: I have a table with 2.5M rows. count(*) on this table is
>
Hi,
I guess this is an age-old 100times answered question, but I didn't find
the answer to it yet (neither in the FAQ nor in the mailing list archives).
Question: I have a table with 2.5M rows. count(*) on this table is
running 4 minutes long. (dual opteron, 4gig ram, db on 4 disk raid10
arr
On Sat, Mar 25, 2006 at 08:11:22PM +0100, Tomaz Borstnar wrote:
> Hello!
>
> First tried some searching around, but did not find anything useful
> so I gave up and decided to ask here... I am wondering how do pair of
> 1.5GHz Itanium2(4MB cache) stack up against pair of AMD or Intel
20 matches
Mail list logo
