Karl Denninger skrev:
> I've got an interesting issue here that I'm running into with 8.2.3
>
> This is an application that has run quite well for a long time, and has
> been operating without significant changes (other than recompilation)
> since back in the early 7.x Postgres days. But now we'r
Aha!
BIG difference. I won't know for sure until the biz day tomorrow but
the "first blush" look is that it makes a HUGE difference in system
load, and I no longer have the stats collector process on the top of the
"top" list..
Karl Denninger ([EMAIL PROTECTED])
http://www.denninger.net
Karl Denninger <[EMAIL PROTECTED]> writes:
> Hm. now that's interesting. Stats collector IS accumulating
> quite a bit of runtime. me thinks its time to go grab 8.2.4.
I think Merlin might have nailed it --- the "stats collector bug" is
that it tries to write out the stats file way m
Hm. now that's interesting. Stats collector IS accumulating
quite a bit of runtime. me thinks its time to go grab 8.2.4.
Karl Denninger ([EMAIL PROTECTED])
http://www.denninger.net
Merlin Moncure wrote:
On 7/25/07, Karl Denninger <[EMAIL PROTECTED]> wrote:
Yeah, the problem
On 7/25/07, Karl Denninger <[EMAIL PROTECTED]> wrote:
Yeah, the problem doesn't appear to be there. As I said, if I look at the
PS of the system when its bogging, there aren't a whole bunch of processes
stuck doing these, so while this does take a second or two to come back,
that's not that ba
Yeah, the problem doesn't appear to be there. As I said, if I look at
the PS of the system when its bogging, there aren't a whole bunch of
processes stuck doing these, so while this does take a second or two to
come back, that's not that bad.
Its GENERAL performance that just bites - the syst
Karl Denninger <[EMAIL PROTECTED]> writes:
> But here's the query that has a habit of taking the most time
> select forum, * from post where toppost = 1 and (replied > (select
> lastview from forumlog where login='theuser' and forum=post.forum and
> number is null)) is not false AND (rep
I've got an interesting issue here that I'm running into with 8.2.3
This is an application that has run quite well for a long time, and has
been operating without significant changes (other than recompilation)
since back in the early 7.x Postgres days. But now we're seeing a LOT
more load tha
On 7/20/07, Josh Berkus <[EMAIL PROTECTED]> wrote:
Jim,
> Has anyone benchmarked HEAD against 8.2? I'd like some numbers to use in
> my OSCon lightning talk. Numbers for both with and without HOT would be
> even better (I know we've got HOT-specific benchmarks, but I want
> complete 8.2 -> 8.3 n
Arnau <[EMAIL PROTECTED]> writes:
>> Alternatively, do you really need to_timestamp at all? The standard
>> timestamp input routine won't have any problem with that format:
>> t.timestamp_in >= '20070101'
> This is always I think I'm worried, what happens if one day the internal
> format in whic
Hi Tom,
Alternatively, do you really need to_timestamp at all? The standard
timestamp input routine won't have any problem with that format:
t.timestamp_in >= '20070101'
This is always I think I'm worried, what happens if one day the internal
format in which the DB stores the date/times
Arnau <[EMAIL PROTECTED]> writes:
> timestamp_in | timestamp without time zone | default now()
> SELECT ...
> FROM
> transactions t
> LEFT OUTER JOIN statistics s ON t.transaction_id = s.transaction_id
> WHERE
> t.timestamp_in >= to_timestamp('20070101', 'MMDD')
> GROUP BY date,
All of the fields are zero except for the three I listed in my posting.
Thanks,
Lance Campbell
Project Manager/Software Architect
Web Services at Public Affairs
University of Illinois
217.333.0382
http://webservices.uiuc.edu
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROT
Hi all,
I've got the following two tables running on postgresql 8.1.4
transactions
Column |Type | Modifiers
--+-+---
transaction_id| character varying(32) | not null
u
> --- Original Message ---
> From: Jean-Max Reymond <[EMAIL PROTECTED]>
> To: pgsql-performance@postgresql.org
> Sent: 24/07/07, 18:23:53
> Subject: Re: [PERFORM] Table Statistics with pgAdmin III
>
> Campbell, Lance a écrit :
> > I have installed pgAdmin III 1.6. In the tool when you c
Campbell, Lance a écrit :
I have installed pgAdmin III 1.6. In the tool when you click on a
particular table you can select a tab called “Statistics”. This tab has
all kinds of info on your table. For some reason the only info I see is
for table size, toast table size and indexes size. Is t
I have installed pgAdmin III 1.6. In the tool when you click on a
particular table you can select a tab called "Statistics". This tab has
all kinds of info on your table. For some reason the only info I see is
for table size, toast table size and indexes size. Is there a reason
that the other 1
Hello,
thank you for all your comments and recommendations.
I'm aware that the conditions for this benchmark are not ideal, mostly
due to the lack of time to prepare it. We will also need an additional
benchmark on a less powerful - more realistic - server to better
understand the scability of
That particular plan is our goal because we've "hacked" it together to
perform better than the normal sql plans. Analytically it makes sense to
approach this particular problem in this way because it is relatively
invariant to the distributions and sizes of the tables (with only having to
deal wit
Jonathan Gray wrote:
Chris,
Creating indexes on the customerclass table does speed up the queries but
still does not create the plan we are looking for (using the double index
with a backward index scan on the orders table).
Stupid question - why is that particular plan your "goal" plan?
The
Chris,
Creating indexes on the customerclass table does speed up the queries but
still does not create the plan we are looking for (using the double index
with a backward index scan on the orders table).
The plans we now get, with times on par or slightly better than with the
plpgsql hack, are:
Chris wrote:
Jonathan Gray wrote:
We’re experiencing a query performance problem related to the planner
and its ability to perform a specific type of merge.
We have created a test case (as attached, or here:
http://www3.streamy.com/postgres/indextest.sql) which involves a
hypothetical cus
Jonathan Gray wrote:
We’re experiencing a query performance problem related to the planner
and its ability to perform a specific type of merge.
We have created a test case (as attached, or here:
http://www3.streamy.com/postgres/indextest.sql) which involves a
hypothetical customer ordering
valgog <[EMAIL PROTECTED]> wrote ..
> On Jul 23, 7:00 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
> > valgog <[EMAIL PROTECTED]> writes:
> > > how to build an multicolumn index with one column order ASCENDING and
> > > another column order DESCENDING?
> >
> > Use 8.3 ;-)
> >
> > In existing releases yo
On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
valgog <[EMAIL PROTECTED]> wrote ..
> On Jul 23, 7:00 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
> > valgog <[EMAIL PROTECTED]> writes:
> > > how to build an multicolumn index with one column order ASCENDING
and
> > > another column order DES
On Jul 23, 7:24 pm, [EMAIL PROTECTED] (Paul van den Bogaard)
wrote:
> the manual somewhere states "... if archiving is enabled..." To me
> this implies that archiving can be disabled. However I cannot find
> the parameter to use to get this result. Or should I enable archiving
> and use a backup sc
26 matches
Mail list logo
