Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-28 Thread Tom Lane
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.

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-28 Thread Rod Taylor
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-28 Thread Tom Lane
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-28 Thread Josh Berkus
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-28 Thread Alban Medici (NetCentrex)
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-25 Thread Bricklen
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-25 Thread Andrew Sullivan
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-22 Thread Matthew T. O'Connor
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-22 Thread Andrew Sullivan
> 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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-21 Thread Gary Doades
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-21 Thread Tom Lane
"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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-21 Thread Thomas F.O'Connell
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-21 Thread Dennis Bjorklund
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

Re: [PERFORM] Performance Anomalies in 7.4.5

2004-10-21 Thread Thomas F . O'Connell
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

[PERFORM] Performance Anomalies in 7.4.5

2004-10-21 Thread Thomas F.O'Connell
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