Rod Taylor <[EMAIL PROTECTED]> writes:
> On Thu, 2004-10-28 at 12:31, Tom Lane wrote:
>> Should be pretty much a fixed cost: one kernel call per table.
> Is this something that the bgwriter could periodically do and share the
> data?
I think a kernel call would be cheaper.
On Thu, 2004-10-28 at 12:31, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> >> One drawback to this is that it would require an additional lseek per table
> >> while planning, but that doesn't seem like a huge penalty.
>
> > Hmmm ... would the additional lseek take longer for larger t
Josh Berkus <[EMAIL PROTECTED]> writes:
>> One drawback to this is that it would require an additional lseek per table
>> while planning, but that doesn't seem like a huge penalty.
> Hmmm ... would the additional lseek take longer for larger tables, or would it
> be a fixed cost?
Should be pret
Tom,
> One drawback to this is that it would require an additional lseek per table
> while planning, but that doesn't seem like a huge penalty.
Hmmm ... would the additional lseek take longer for larger tables, or would it
be a fixed cost?
--
Josh Berkus
Aglio Database Solutions
San Francisco
nnell
Cc: PgSQL - Performance
Subject: Re: [PERFORM] Performance Anomalies in 7.4.5
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> -> Nested Loop (cost=0.00..0.01 rows=1 width=8) (actual
> time=1.771..298305.531 rows=2452 loops=1)
> Join Filter: (&quo
Thomas F.O'Connell wrote:
I'm seeing some weird behavior on a repurposed server that was wiped
clean and set up to run as a database and application server with
postgres and Apache, as well as some command-line PHP scripts.
The box itself is a quad processor (2.4 GHz Intel Xeons) Debian woody
On Fri, Oct 22, 2004 at 05:13:18PM -0400, Matthew T. O'Connor wrote:
> Yes that is the long term goal, but the autovac in 8.0 is still all or
> nothing.
Yes, which is why I couldn't use the current iteration for
production: the cost is too high. I think this re-inforces my
original point, which
Andrew Sullivan wrote:
Probably the most severe objection to doing things this way is that the
selected plan could change unexpectedly as a result of the physical
table size changing. Right now the DBA can keep tight rein on actions
that might affect plan selection (ie, VACUUM and ANALYZE), but th
> Probably the most severe objection to doing things this way is that the
> selected plan could change unexpectedly as a result of the physical
> table size changing. Right now the DBA can keep tight rein on actions
> that might affect plan selection (ie, VACUUM and ANALYZE), but that
> would go
On 21 Oct 2004 at 15:50, Thomas F.O'Connell wrote:
> If not, should I be REINDEXing manually, as well as VACUUMing manually
> after large data imports (whether via COPY or INSERT)? Or will a VACUUM
> FULL ANALYZE be enough?
>
It's not the vacuuming that's important here, just the analyze. If
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> -> Nested Loop (cost=0.00..0.01 rows=1 width=8) (actual
> time=1.771..298305.531 rows=2452 loops=1)
> Join Filter: ("inner".id = "outer".id)
> -> Seq Scan on userdata u (cost=0.00..0.00 rows=1 width=8)
> (actual time
The irony is that I had just disabled pg_autovacuum the previous day
during analysis of a wider issue affecting imports of data into the
system.
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203
On Thu, 21 Oct 2004, Thomas F.O'Connell wrote:
> Aggregate (cost=0.02..0.02 rows=1 width=8) (actual
> time=298321.421..298321.422 rows=1 loops=1)
> -> Nested Loop (cost=0.00..0.01 rows=1 width=8) (actual
> time=1.771..298305.531 rows=2452 loops=1)
> Join Filter: ("inner".id
I know, I know: I should've done this before I posted. REINDEXing and
VACUUMing mostly fixed this problem. Which gets me back to where I was
yesterday, reviewing an import process (that existed previously) that
populates tables in this system that seems to allow small data sets to
cause sim
I'm seeing some weird behavior on a repurposed server that was wiped
clean and set up to run as a database and application server with
postgres and Apache, as well as some command-line PHP scripts.
The box itself is a quad processor (2.4 GHz Intel Xeons) Debian woody
GNU/Linux (2.6.2) system
15 matches
Mail list logo