"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Well, I'm not even sure if those got applied or were just Tom hacking
> in the basement or, heck, my fevered imagination. :)
For the record, I hack in the attic ... or what I tell the IRS is my
third-floor office ...
regards, t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 19 Dec 2007 19:51:13 -0600
Decibel! <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007, at 4:54 PM, Gregory Stark wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >
> >> It is pretty much common knowledge that
> >
> > I think we have too m
On Dec 19, 2007, at 6:39 PM, Tom Lane wrote:
The thing that concerns me is dead tuples on the table_stats
table. I
believe that every insert of new data in one of the monitored tables
will result in an UPDATE of the table_stats table. When thousands
( or millions ) of rows are inserted, the s
On Dec 19, 2007, at 4:54 PM, Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
It is pretty much common knowledge that
I think we have too much "common knowledge".
Yeah. For a lot of folks it's still common knowledge that you should
only set shared_buffers to 10% of memo
On Dec 8, 2007, at 1:06 AM, Greg Smith wrote:
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
Dan Harris <[EMAIL PROTECTED]> writes:
> The thing that concerns me is dead tuples on the table_stats table. I
> believe that every insert of new data in one of the monitored tables
> will result in an UPDATE of the table_stats table. When thousands
> ( or millions ) of rows are inserted, t
I've been fighting with the common workarounds for inadequate response
times on select count(*) and min(),max() on tables with tens of
millions of rows for quite a while now and understand the reasons for
the table scans.
I have applications that regularly poll a table ( ideally, the more
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> It is pretty much common knowledge that
I think we have too much "common knowledge".
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
---(end of broadcas
Gregory Stark wrote:
"Richard Huxton" <[EMAIL PROTECTED]> writes:
Paul Lambert wrote:
" -> Sort (cost=30197.98..30714.85 rows=206748 width=16) (actual >>
time=5949.691..7018.931 rows=206748 loops=1)"
"Sort Key: dealer_id, year_id, subledger_id, account_id"
"Sort Method: e
On Wed, 19 Dec 2007, Ron Mayer wrote:
Benchmarks I see[1] suggest that 8.1.2 scaled pretty reasonably to 16
cores (from the chart on page 9 in the link below). But yeah, 8.0
scaled to maybe 2 cores if you're lucky. :-)
[1]
http://www.pgcon.org/2007/schedule/attachments/22-Scaling%20PostgreSQL%
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 19 Dec 2007 11:14:08 -0800
Ron Mayer <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
> > Actually this is not true. Although I have yet to test 8.3. It is
> > pretty much common knowledge that after 8 cores the acceleration of
> > performa
Joshua D. Drake wrote:
> Actually this is not true. Although I have yet to test 8.3. It is
> pretty much common knowledge that after 8 cores the acceleration of
> performance drops with PostgreSQL...
>
> This has gotten better every release. 8.1 for example handles 8 cores
> very well, 8.0 didn't
On Dec 19, 2007 1:07 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 19 Dec 2007 13:03:32 -0600
> "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
>
>
> > > Actually this is not true. Although I have yet to test 8.3. It is
> > > pretty much com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 19 Dec 2007 13:03:32 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> > Actually this is not true. Although I have yet to test 8.3. It is
> > pretty much common knowledge that after 8 cores the acceleration of
> > performance drops with Pos
On Dec 19, 2007 12:59 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 19 Dec 2007 13:50:29 -0500 (EST)
> Greg Smith <[EMAIL PROTECTED]> wrote:
>
> > > With PG 8.2 and 8.3, is it still pretty much limited to 8 cores
> > > making 2 of the q
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 19 Dec 2007 13:50:29 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
> > With PG 8.2 and 8.3, is it still pretty much limited to 8 cores
> > making 2 of the quad core Xeons redundant or detrimental?
>
> Where'd you get the idea 8 cores was
On Wed, 19 Dec 2007, Stuart Bishop wrote:
For pgbench (PG 8.2 running Ubuntu), the Opteron is getting about 6x TPS
over the Xeon (3000+ TPS on Opteron vs ~500 on Xeon). Things get a little
better for Xeon with PG 8.3 (570-540 TPS).
The 3000+ TPS figure is the correct one for a controller that
Paul Lambert wrote:
"-> Merge Join
(cost=35.56..19732.91 rows=12 width=48) (actual time=0.841..2309.828
rows=206748 loops=1)"
I'm no expert, but in the interests of learning: why is the
rows estimate so far out for this join?
Thanks,
Jeremy
--
Roberts, Jon escribió:
> The more I thought about a counter proposal to put views on pg_proc, I
> realized that isn't feasible either. It would break functionality of
> pgAdmin because users couldn't view their source code with the tool.
What's wrong with patching pgAdmin?
--
Alvaro Herrera
> -Original Message-
> From: Trevor Talbot [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 19, 2007 9:45 AM
> To: Joshua D. Drake
> Cc: Roberts, Jon; Kris Jurka; Merlin Moncure; Jonah H. Harris; Bill Moran;
> pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] viewing source co
On 12/18/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Dec 2007 10:05:46 -0600
> "Roberts, Jon" <[EMAIL PROTECTED]> wrote:
> > If we are talking about enhancement requests, I would propose we
> > create a role that can be granted/revoked that enables a user to see
> > dictionary obj
On Dec 19, 2007 6:04 AM, Stuart Bishop <[EMAIL PROTECTED]> wrote:
> Hi.
>
> We are looking at upgrading our primary servers. The final boxes will have
> 128GB ram, fast disk arrays and 4 CPUs.
>
> We currently have some eval units with 8GB ram and crappy disk to let us
> benchmark CPU choice. One b
"Stuart Bishop" <[EMAIL PROTECTED]> writes:
> For pgbench (PG 8.2 running Ubuntu), the Opteron is getting about 6x TPS
> over the Xeon (3000+ TPS on Opteron vs ~500 on Xeon). Things get a little
> better for Xeon with PG 8.3 (570-540 TPS).
There was a problem in the past which affected Xeons. But
Stuart Bishop a écrit :
Hi.
We are looking at upgrading our primary servers. The final boxes will have
128GB ram, fast disk arrays and 4 CPUs.
We currently have some eval units with 8GB ram and crappy disk to let us
benchmark CPU choice. One box has 4 3GHz dual core Opterons with 1MB cache,
the
Hi.
We are looking at upgrading our primary servers. The final boxes will have
128GB ram, fast disk arrays and 4 CPUs.
We currently have some eval units with 8GB ram and crappy disk to let us
benchmark CPU choice. One box has 4 3GHz dual core Opterons with 1MB cache,
the other box ha 4 3GHz quad
> Also, try replacing the DISTINCT with GROUP BY. The code path for DISTINCT
> unfortunately needs a bit of cleaning up and isn't exactly equivalent to GROUP
> BY. In particular it doesn't support hash aggregates which, if your work_mem
> is large enough, might work for you here.
Sorry, strike th
"Richard Huxton" <[EMAIL PROTECTED]> writes:
> Paul Lambert wrote:
>
>> " -> Sort (cost=30197.98..30714.85 rows=206748 width=16) (actual >>
>> time=5949.691..7018.931 rows=206748 loops=1)"
>> "Sort Key: dealer_id, year_id, subledger_id, account_id"
>> "Sort Method: external me
Paul Lambert wrote:
Paul Lambert wrote:
This part of the query alone takes a significant part of the time:
SELECT DISTINCT ON (finbalance.dealer_id, finbalance.year_id,
finbalance.subledger_id, finbalance.account_id)
finbalance.year_id AS year,
finbalance.dealer_id
28 matches
Mail list logo
