On Sun, Jun 20, 2010 at 2:04 PM, Greg Smith wrote:
> It's hard to run a 24x7 environment on 8.1. Much easier on 8.4, where the
> major things that regularly left people with quite bad VACUUM cleanup
> situations are all less likely to occur than on any previous version.
Here here. keeping anyt
On Sun, Jun 20, 2010 at 11:44 AM, Jesper Krogh wrote:
> Hi.
>
> I have been wondering if anyone has been experimenting with "really
> agressive"
> autovacuuming.
I have been using moderately aggressive autovac, with 6 or more
threads running with 1ms sleep, then keeping track of them to see if
th
venu madhav wrote:
The problem here is even though some records are cleared, it still
shows the original DB Size. Is there any way to find out the actual DB
Size or it would be more useful, if I can get the size of each table.
One of the queries at http://wiki.postgresql.org/wiki/Disk_Usage sh
Robert Haas wrote:
This is drifting a bit off-topic for this thread, but it's not so easy
to figure out from looking at the TODO which things are actually
important. Performance-related improvements are mixed in with
non-performance related improvements, which are mixed in with things
that are p
Hi.
I have been wondering if anyone has been experimenting with "really
agressive"
autovacuuming. The database I'm adminstrating rarely have "long running"
transactions
(over several minutes). And a fair amount of buffercache and an OS cache of
(at best 64GB). A lot of the OS cache is being us
Dave Crooke writes:
> 4. If you're trying to figure out the net size of the table, i.e. how much
> free space is inside the table files for reuse by PG, then you need the
> pg_stat_tuple function ... this is built in to PG 8.4, and a plug-in
> activated by a script for PG 8.3, don't know if it exi
"Davor J." writes:
> Suppose 2 functions: factor(int,int) and offset(int, int).
> Suppose a third function: convert(float,int,int) which simply returns
> $1*factor($2,$3)+offset($2,$3)
> All three functions are IMMUTABLE.
You should write the third function as a SQL function, which'd allow it
to
AI Rumman wrote:
> Which one is good - join between table or using exists in where
> condition?
Your example wouldn't return the same results unless there was at
most one matching row in b and one matching row in c, at least
without resorting to DISTINCT (which you don't show). So, be careful
Hi there
1. PG 8.1.9 is ancient ... you should upgrade.
2. The database gross size on disk is not affected by VACUUM ANALYZE ... all
this does is return space used by deleted row-versions to PG for re-use. The
only way to reduce it and thus return disk space to the OS is to do a VACUUM
FULL, or t
I didn't consider them to be important as they showed the same, only the
execution time was different. Also, they are a bit more complex than the ones
put in the previous post. But here they are:
Definitions:
---
CREATE OR REPLACE FUNCTION
2010/6/19 Davor J.
> I think I have read what is to be read about queries being prepared in
> plpgsql functions, but I still can not explain the following, so I thought
> to post it here:
>
> Suppose 2 functions: factor(int,int) and offset(int, int).
> Suppose a third function: convert(float,int,
I think I have read what is to be read about queries being prepared in
plpgsql functions, but I still can not explain the following, so I thought
to post it here:
Suppose 2 functions: factor(int,int) and offset(int, int).
Suppose a third function: convert(float,int,int) which simply returns
$1*
Hi,
I've noticed something that I find strange with the hash-aggregate
feature of Postgres. I'm currently running Postgres v8.4.1 on Debian
Linux 64-bit.
I have a simple query that when planned either uses hash-aggregates or a
sort depending on the amount of working memory available. The problem
Hi All,
I am using Postgres 8.1.9 for my application. My application also has
a clean up module which cleans up specified percentage of total database
size at regular intervals. Now the problem is I use *pg_database_size* to
obtain the size of the database. After deleting the records, we run
Which one is good - join between table or using exists in where condition?
Query 1;
Select a.*
from a
where exists
(
select 1 from b inner join c on b.id1 = c.id where a.id = b.id)
Query 2:
select a.*
from a
inner join
(select b.id from b inner join c on b.id1 = c.id) as q
on a.id = q.id
Any su
15 matches
Mail list logo
