kelvan wrote:
hi i need to know all the database overhead sizes and block header sizes etc
etc as I have a very complex database to build and it needs to be speed
tuned beyond reckoning
[snip]
I am using postgres 8.1 if anyone can post links to pages containing over
head information and inde
=?ISO-8859-2?Q?Piotr_Gasid=B3o?= <[EMAIL PROTECTED]> writes:
> I've just hit problem, that is unusual for me.
> View definition:
> SELECT users.id, users.user_name, users.extra IS NOT NULL AS has_extra
> FROM users;
What you've got here is a non-nullable target list, which creates an
optimi
Hello,
I've just hit problem, that is unusual for me.
quaker=> \d sites
Table "public.sites"
Column | Type| Modifiers
---+---+
id| integer
Hi,
I'm currently trying to tune the Cost-Based Vacuum Delay in a
8.2.5 server. The aim is to reduce as much as possible the
performance impact of vacuums on application queries, with the
background idea of running autovacuum as much as possible[1].
My test involves vacuuming a large table, and m
On Fri, 2007-12-07 at 12:45 +1200, kelvan wrote:
> hi i need to know all the database overhead sizes and block header sizes etc
> etc as I have a very complex database to build and it needs to be speed
> tuned beyond reckoning
If your need-for-speed is so high, I would suggest using 8.3 or at l
On Dec 7, 2007, at 4:50 AM, Guillaume Cottenceau wrote:
Hi,
I'm currently trying to tune the Cost-Based Vacuum Delay in a
8.2.5 server. The aim is to reduce as much as possible the
performance impact of vacuums on application queries, with the
background idea of running autovacuum as much as p
On Thursday 06 December 2007 04:38, Simon Riggs wrote:
> Robert,
>
> On Wed, 2007-12-05 at 15:07 -0500, Robert Treat wrote:
> > If the whole performance of your system depends upon indexed access, then
> > maybe you need a database that gives you a way to force index access at
> > the query level?
"Simon Riggs" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Fri, 2007-12-07 at 12:45 +1200, kelvan wrote:
>
>> hi i need to know all the database overhead sizes and block header sizes
>> etc
>> etc as I have a very complex database to build and it needs to be speed
>> tuned be
One of those things that comes up regularly on this list in particular are
people whose performance issues relate to "bloated" tables or indexes.
What I've always found curious is that I've never seen a good way
suggested to actually measure said bloat in any useful numeric
terms--until today.
Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> There's something fishy about this --- given that that plan has a lower
>>> cost estimate, it should've picked it without any artificial
>>> constraints.
One final thing I find curious about this is that the estimated
n
On Dec 7, 2007, at 10:44 AM, Guillaume Cottenceau wrote:
Erik Jones writes:
vacuum_cost_delay/vacuum_cost_limit (deactivated) 20/200
40/200 100/1000 150/1000 200/1000 300/1000
VACUUM ANALYZE time54 s112 s188
s109 s 152 s 190 s
Erik Jones writes:
>> vacuum_cost_delay/vacuum_cost_limit (deactivated) 20/200
>> 40/200 100/1000 150/1000 200/1000 300/1000
>>
>> VACUUM ANALYZE time54 s112 s188
>> s109 s 152 s 190 s 274 s
>> SELECT time
12 matches
Mail list logo
