The bitmask allows the setting of multiple permissions but the table
definition doesn't have to change (well, so long as the bits fit into a
word!) Finally, this is a message forum - the actual code itself is
template-driven and the bitmask permission structure is ALL OVER the
templates;
Karl Denninger wrote:
The bitmask allows the setting of multiple permissions but the table
definition doesn't have to change (well, so long as the bits fit into a
word!) Finally, this is a message forum - the actual code itself is
template-driven and the bitmask permission structure is ALL
On Tue, 18 Aug 2009, Tom Lane wrote:
- Index Scan using locationbin8000__subjectobjectbin on
locationbin8000 l1
(cost=0.00..71635.23 rows=657430 width=20)
(actual time=0.056..170.857 rows=664588 loops=1)
Index
I'm on a CentOS 5 OS 64 bit, latest kernel and all of that.
PG version is 8.3.7, compiled as 64bit.
The memory is 8GB.
It's a 2 x Dual Core Intel 5310.
Hard disks are Raid 1, SCSI 15 rpm.
The server is running just one website. So there's Apache 2.2.11,
MySQL (for some small tasks, almost
Phoenix Kiula wrote:
I'm on a CentOS 5 OS 64 bit, latest kernel and all of that.
PG version is 8.3.7, compiled as 64bit.
The memory is 8GB.
It's a 2 x Dual Core Intel 5310.
Hard disks are Raid 1, SCSI 15 rpm.
The server is running just one website. So there's Apache 2.2.11,
MySQL (for some
Ivan Voras ivoras 'at' freebsd.org writes:
pgtop (http://pgfoundry.org/projects/pgtop/) might help you see what
is your database doing.
A simpler (but most probably less powerful) method would be to
activate stats_command_string = on in the server configuration,
then issue that query to view
Phoenix Kiula wrote:
I'm on a CentOS 5 OS 64 bit, latest kernel and all of that.
PG version is 8.3.7, compiled as 64bit.
The memory is 8GB.
It's a 2 x Dual Core Intel 5310.
Hard disks are Raid 1, SCSI 15 rpm.
The server is running just one website. So there's Apache 2.2.11,
MySQL (for some
Andy Colson wrote:
Phoenix Kiula wrote:
I'm on a CentOS 5 OS 64 bit, latest kernel and all of that.
PG version is 8.3.7, compiled as 64bit.
The memory is 8GB.
It's a 2 x Dual Core Intel 5310.
Hard disks are Raid 1, SCSI 15 rpm.
The server is running just one website. So there's Apache
On Wed, Aug 19, 2009 at 11:25 PM, Andy Colsona...@squeakycode.net wrote:
snip.
the first line of vmstat is an average since bootup. Kinda useless. run it
as: 'vmstat 4'
it will print a line every 4 seconds, which will be a summary of everything
that happened in the last 4
Kevin Grittner wrote:
Andy Colson a...@squeakycode.net wrote:
Phoenix Kiula wrote:
It's a 2 x Dual Core Intel 5310.
you have average 74% idle cpu. So your not cpu bound either?
Or one CPU is pegged and the other three are idle
-Kevin
Ahh, yeah...
Phoenix: run top again, and
On Wed, 19 Aug 2009, Phoenix Kiula wrote:
~ vmstat 4
procs ---memory-- ---swap-- -io --system-- cpu
r b swpd free buff cache si sobibo incs us sy id wa
0 2 16128 35056 62800 76974280074 1530 3 10 5 74 12
0 0
On Wed, Aug 19, 2009 at 11:37 PM, Andy Colsona...@squeakycode.net wrote:
Phoenix: run top again, and hit the '1' key. It'll show you stats for
each
cpu. Is one pegged and the others idle?
top - 10:38:53 up 29 days, 5 min, 1 user, load average: 64.99, 65.17,
65.06
Tasks: 568 total, 1
Phoenix Kiula wrote:
On Wed, Aug 19, 2009 at 11:37 PM, Andy Colsona...@squeakycode.net
mailto:a...@squeakycode.net wrote:
Phoenix: run top again, and hit the '1' key. It'll show you stats
for each
cpu. Is one pegged and the others idle?
top - 10:38:53 up 29 days, 5 min, 1 user,
Phoenix Kiula phoenix.ki...@gmail.com writes:
top - 10:38:53 up 29 days, 5 min, 1 user, load average: 64.99, 65.17,
65.06
Tasks: 568 total, 1 running, 537 sleeping, 6 stopped, 24 zombie
Cpu0 : 17.7% us, 7.7% sy, 0.0% ni, 74.0% id, 0.7% wa, 0.0% hi, 0.0% si
Cpu1 : 6.3% us, 5.6%
Phoenix Kiula phoenix.kiula 'at' gmail.com writes:
Tasks: 568 total, 1 running, 537 sleeping, 6 stopped, 24 zombie
The stopped and zombie processes look odd. Any reason for these?
--
Guillaume Cottenceau
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To
On Wed, Aug 19, 2009 at 9:40 AM, Phoenix Kiulaphoenix.ki...@gmail.com wrote:
On Wed, Aug 19, 2009 at 11:37 PM, Andy Colsona...@squeakycode.net wrote:
Phoenix: run top again, and hit the '1' key. It'll show you stats for
each
cpu. Is one pegged and the others idle?
top - 10:38:53 up 29
Hi all;
we've been fighting this query for a few days now. we bumped up the statistict
target for the a.id , c.url_hits_id and the b.id columns below to 250 and ran
an analyze on the relevant tables. we killed it after 8hrs.
Note the url_hits table has 1.4billion rows
Any suggestions?
that seems to be the killer:
and time = extract ('epoch' from timestamp '2009-08-12')
and time extract ('epoch' from timestamp '2009-08-13' )
You probably need an index on time/epoch:
CREATE INDEX foo ON table(extract ('epoch' from timestamp time );
or something like that, vacuum analyze and
2009/8/19 Grzegorz Jaśkiewicz gryz...@gmail.com
that seems to be the killer:
and time = extract ('epoch' from timestamp '2009-08-12')
and time extract ('epoch' from timestamp '2009-08-13' )
You probably need an index on time/epoch:
CREATE INDEX foo ON table(extract ('epoch' from
On Wednesday 19 August 2009 11:17:26 Scott Carey wrote:
On 8/19/09 9:28 AM, Kevin Kempter kev...@consistentstate.com wrote:
Hi all;
we've been fighting this query for a few days now. we bumped up the
statistict target for the a.id , c.url_hits_id and the b.id columns below
to 250 and
On Wednesday 19 August 2009 11:31:30 Nikolas Everett wrote:
2009/8/19 Grzegorz Jaśkiewicz gryz...@gmail.com
that seems to be the killer:
and time = extract ('epoch' from timestamp '2009-08-12')
and time extract ('epoch' from timestamp '2009-08-13' )
You probably need an index on
Hi,
AFAIUI, work_mem is used for some operations (sort, hash, etc) for
avoiding the use of temp files on disk...
In a client server i'm monitoring (pg 8.3.7, 32GB of ram) work_mem is
set to 8MB, however i'm seeing a lot of temp files (3 in 4 hours)
with small sizes (ie: 2021520 obviously
22 matches
Mail list logo
