I have a table in Postgresql 9.0.1 as folllows:
Table "public.crmentity"
Column|Type | Modifiers
--+-+
crmid| integer | not null
smcreatorid | integer
On 15/12/10 09:12, Dave Crooke wrote:
There is a plugin called pgstattuple which can be quite informative
however, it actually does a full scan of the table / index files,
which may be a bit invasive depending on your environment and load.
http://www.postgresql.org/docs/current/static/pgs
There is a plugin called pgstattuple which can be quite informative
however, it actually does a full scan of the table / index files, which may
be a bit invasive depending on your environment and load.
http://www.postgresql.org/docs/current/static/pgstattuple.html
It's in the contrib (at lea
Hey all-
Glad to know you are still interested... ;)
Didn't mean to leave you hanging, the holiday and all have put some
bumps in the road.
Dan my co-worker might be able to post some more detailed information
here, but here is a brief summary of what I am aware of:
1. We have not tested a
BTW, have you tried prepared statements? bytea is most likely faster (in part)
due to less parsing in the backend. Prepared statements would eliminate that
parsing step.
On Dec 14, 2010, at 10:07 AM, Nick Matheson wrote:
> Hey all-
>
> Glad to know you are still interested... ;)
>
> Didn't me
Can you explain this query a bit? It isn't at all clear to me.
Plugge, Joe R. wrote:
I have used this in the past ... run this against the database that you want to
inspect.
SELECT
current_database(), schemaname, tablename, /*reltuples::bigint,
relpages::bigint, otta,*/
ROUND(CASE WHEN
On 12/14/2010 9:41 AM, Jim Nasby wrote:
On Dec 14, 2010, at 9:27 AM, Andy Colson wrote:
Is this the same thing Nick is working on? How'd he get along?
http://archives.postgresql.org/message-id/4cd1853f.2010...@noaa.gov
So it is. The one I replied to stood out because no one had replied to it
On Dec 14, 2010, at 9:27 AM, Andy Colson wrote:
> Is this the same thing Nick is working on? How'd he get along?
>
> http://archives.postgresql.org/message-id/4cd1853f.2010...@noaa.gov
So it is. The one I replied to stood out because no one had replied to it; I
didn't see the earlier email.
--
On 11/1/2010 9:15 AM, Dan Schaffer wrote:
Hello
We have an application that needs to do bulk reads of ENTIRE Postgres
tables very quickly (i.e. select * from table). We have observed that
such sequential scans run two orders of magnitude slower than observed
raw disk reads (5 MB/s versus 100 MB/
I have used this in the past ... run this against the database that you want to
inspect.
SELECT
current_database(), schemaname, tablename, /*reltuples::bigint,
relpages::bigint, otta,*/
ROUND(CASE WHEN otta=0 THEN 0.0 ELSE sml.relpages/otta::numeric END,1) AS
tbloat,
CASE WHEN relpages <
How can you tell when your indexes are starting to get bloated and when you
need to rebuild them. I haven't seen a quick way to tell and not sure if it's
being tracked.
___
| John W. Strange | Investment
Thanks guys - interesting.
On 14/12/2010, at 5:59 AM, Josh Berkus wrote:
> On 12/12/10 6:43 PM, Royce Ausburn wrote:
>> Hi all,
>>
>> I notice that when restoring a DB on a laptop with an SDD, typically
>> postgres is maxing out a CPU - even during a COPY. I wonder, what is
>> postgres usu
12 matches
Mail list logo
