On 10/2/07, Decibel! [EMAIL PROTECTED] wrote:
On Sep 21, 2007, at 4:43 AM, Gregory Stark wrote:
Csaba Nagy [EMAIL PROTECTED] writes:
On Fri, 2007-09-21 at 09:03 +0100, Gregory Stark wrote:
Mem: 32945280k total, 32871832k used,73448k free,
247432k buffers
Swap: 1951888k total,
On Sep 21, 2007, at 4:43 AM, Gregory Stark wrote:
Csaba Nagy [EMAIL PROTECTED] writes:
On Fri, 2007-09-21 at 09:03 +0100, Gregory Stark wrote:
Mem: 32945280k total, 32871832k used,73448k free,
247432k buffers
Swap: 1951888k total,42308k used, 1909580k free,
30294300k cached
But then why is it not reporting that in the Swap: used
section ? It
only reports 42308k used swap.
Hm, good point.
The other possibility is that Postgres just hasn't even touched a
large part
of its shared buffers.
Sorry for the late reply...
No, this is on a very active
Hi List;
any suggestions for improving LIKE '%text%' queries?
Thanks in advance
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Kempter wrote:
Hi List;
any suggestions for improving LIKE '%text%' queries?
faster disks :)
take a look at pg_tgrm and tsearch2.
Sincerely,
Joshua D. Drake
Thanks in advance
---(end of
On 10/2/07, Kevin Kempter [EMAIL PROTECTED] wrote:
Hi List;
any suggestions for improving LIKE '%text%' queries?
http://www.depesz.com/index.php/2007/09/15/speeding-up-like-xxx/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Hello everybody,
I have just joined the list, as I am experiencing a degradation on
performances on my PostgreSQL instance, and I was looking for some
insights on how to fix/avoid it.
What I have observed are impossibly high time on delete statements on
some tables.
The delete statement is very
On 2 Oct 2007 at 23:55, Giulio Cesare Solaroli wrote:
What I have observed are impossibly high time on delete statements on
some tables.
The delete statement is very simple:
delete from table where pk = ?
The explain query report a single index scan on the primary key index,
as
On Oct 2, 2007, at 1:37 PM, Adam Tauno Williams wrote:
I'm leaning towards top on linux == dumb.
I disagree, it just isn't the appropriate tool for the job. What top
tells you is lots of correct information, it just isn't the right
information.
If it is in fact including shared memory as
[EMAIL PROTECTED] (Kevin Kempter) writes:
any suggestions for improving LIKE '%text%' queries?
If you know that the 'text' portion of that query won't change, then
you might create a partial index on the boolean condition.
That is,
create index index_foo_text on my_table (tfield) where
Giulio Cesare Solaroli wrote:
Hello everybody,
I have just joined the list, as I am experiencing a degradation on
performances on my PostgreSQL instance, and I was looking for some
insights on how to fix/avoid it.
What I have observed are impossibly high time on delete statements on
some
Hi,
I have recently had to change our nightly jobs from running vacuum
full, as it has caused problems for us. Upon doing more reading on
this topic, I understand that vacuum full needs explicit locks on the
entire db and explicit locking conflicts with all other locks.
But this has bought me to
On 10/2/07, Radhika S [EMAIL PROTECTED] wrote:
Hi,
I have recently had to change our nightly jobs from running vacuum
full, as it has caused problems for us. Upon doing more reading on
this topic, I understand that vacuum full needs explicit locks on the
entire db and explicit locking
On Tue, 2 Oct 2007 21:45:37 -0400
Radhika S [EMAIL PROTECTED] wrote:
But this has bought me to the question of what exactly is the
difference between vacuum and vacuum full. If both give back free
space to the disk, then why have vacuum full.
Not quite. VACUUM FULL returns space to the
Thank you much for such a precise explanation. That was very helpful.
Regards,
Radhika
On 10/2/07, Scott Marlowe [EMAIL PROTECTED] wrote:
On 10/2/07, Radhika S [EMAIL PROTECTED] wrote:
Hi,
I have recently had to change our nightly jobs from running vacuum
full, as it has caused
15 matches
Mail list logo
