Josh Berkus <[EMAIL PROTECTED]> writes:
> So memcached becomes a very good place to stick data that's read often but
> not
> updated often, or alternately data that changes often but is disposable. An
> example of the former is a user+ACL list; and example of the latter is web
> session info
On Tue, 16 Nov 2004, Simon Riggs wrote:
> The join condition has so many ANDed predicates that we assume that this
> will reduce the selectivity considerably. It does not, and so you pay
> the cost dearly later on.
>
Yes, that makes a lot of sense. Without some incredibly good cross-column
st
Oh, I didn't realize that analyze gave that much more info. I've got a
lot to learn about this tuning stuff ;-)
I've attached the output. I see from the new output where the slow query
is taking its time (the nested loop at line 10), but I still have no
idea why this plan is getting chosen
T
>If they are the same and PostgreSQL are the same, are the
>intel machines Xeons?
Yup, dual 3.06-GHz Intel Xeon Processors.
I'm not sure off the top of my head what the sparcs are exactly. We're
in the process of moving completely to intel, but we still have to
support our app on sparc, and we a
On Nov 17, 2004, at 7:32 AM, David Parker wrote:
Oh, I didn't realize that analyze gave that much more info. I've got a
lot to learn about this tuning stuff ;-)
I've attached the output. I see from the new output where the slow
query
is taking its time (the nested loop at line 10), but I still hav
I've got pg_autovacuum running on both platforms. I've verified that the
tables involved in the query have the same number of rows on both
databases.
I'm not sure where to look to see how the stats might be different. The
"good" database's pg_statistic table has 24 more rows than that in the
"bad"
Hmm, I'm really a beginner at this...
It turns out that the pg_statistic table in my good database has records
in it for the tables in the query, while the pg_statistic table in my
bad database has no records for those tables at all!
So I guess I need to figure out why pg_autovacuum isn't analyzi
"David Parker" <[EMAIL PROTECTED]> writes:
> So I guess I need to figure out why pg_autovacuum isn't analyzing those
> tables.
Which autovacuum version are you using? The early releases had some
nasty bugs that would allow it to skip tables sometimes. I think all
the known problems are fixed as
We're using postgresql 7.4.5. I've only recently put pg_autovacuum in
place as part of our installation, and I'm basically taking the
defaults. I doubt it's a problem with autovacuum itself, but rather with
my configuration of it. I have some reading to do, so any pointers to
existing autovacuum th
I'm doing some performance profiling with a simple two-table query:
SELECT L."ProductID", sum(L."Amount")
FROM "drinv" H
JOIN "drinvln" L ON L."OrderNo" = H."OrderNo"
WHERE
("OrderDate" between '2003-01-01' AND '2003-04-30')
GROUP BY L."ProductID"
drinv and drinvln have about 100,000 and 3,500,00
On 17 Nov 2004 03:08:20 -0500, Greg Stark <[EMAIL PROTECTED]> wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>
> > So memcached becomes a very good place to stick data that's read often but
> > not
> > updated often, or alternately data that changes often but is disposable.
> > An
> > exampl
David Parker wrote:
We're using postgresql 7.4.5. I've only recently put pg_autovacuum in
place as part of our installation, and I'm basically taking the
defaults. I doubt it's a problem with autovacuum itself, but rather with
my configuration of it. I have some reading to do, so any pointers to
ex
On November 16, 2004 08:00 pm, Michael Adler wrote:
> http://pugs.postgresql.org/sfpug/archives/21.html
>
> I noticed that some of you left coasters were talking about memcached
> and pgsql. I'm curious to know what was discussed.
>
> In reading about memcached, it seems that many people are us
Oleg,
Sorry but when I do your request I get :
# select id_site from site where idx_site_name @@ 'livejourn';
ERROR: type " " does not exist
What is this ?
(private: I don't know what happend with my mail, but I do nothing special to
disturb the contains when I'm writting to you ...)
Le Mard
1;2c1;2c1;2cOn Wed, 17 Nov 2004, [iso-8859-15] Herv? Piedvache wrote:
Oleg,
Sorry but when I do your request I get :
# select id_site from site where idx_site_name @@ 'livejourn';
ERROR: type " " does not exist
no idea :) btw, what version of postgresql and OS you're running.
Could you try minima
Well based on the autovacuum log that you attached, all of those tables
are insert only (at least during the time period included in the log.
Is that correct? If so, autovacuum will never do a vacuum (unless
required by xid wraparound issues) on those tables. So this doesn't
appear to be an
Dan,
> I'm doing some performance profiling with a simple two-table query:
Please send EXPLAIN ANALYZE for each query, and not just EXPLAIN. Thanks!
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you
On Wed, Nov 17, 2004 at 09:13:09AM -0800, Darcy Buskermolen wrote:
> On November 16, 2004 08:00 pm, Michael Adler wrote:
> > http://pugs.postgresql.org/sfpug/archives/21.html
> >
> > I noticed that some of you left coasters were talking about memcached
> > and pgsql. I'm curious to know what wa
Hello,
Have you tried increasing the statistics target for orderdate and
rerunning analyze?
Sincerely,
Joshua D. Drake
David Brown wrote:
I'm doing some performance profiling with a simple two-table query:
SELECT L."ProductID", sum(L."Amount")
FROM "drinv" H
JOIN "drinvln" L ON L."OrderNo" = H."O
Michael,
> Still, it seems like a convenient way to maintain cache coherency,
> assuming that your application doesn't already have a clean way to do
> that.
Precisely.The big problem with memory caching is the cache getting out of
sync with the database. Updating the cache through databas
I understand that the sort_mem conf setting affects queries with order by,
etc., and the doc mentions that it is used in create index. Does sort_mem
affect the updating of indexes, i.e., can the sort_mem setting affect the
performance of inserts?
- DAP
--
David,
> I understand that the sort_mem conf setting affects queries with order by,
> etc., and the doc mentions that it is used in create index. Does sort_mem
> affect the updating of indexes, i.e., can the sort_mem setting affect the
> performance of inserts?
Only if the table has Foriegn Keys
Hi,
in March there was an interesting discussion on the list with the
subject "postgres eating CPU on HP9000".
Now I'm the same problem on a Dell dual processor machine.
Anybody know if there was a solution?
Thanks
Piergiorgio
---(end of broadcast)-
> in March there was an interesting discussion on the list with the
> subject "postgres eating CPU on HP9000".
Link, please?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list
On Thu, 2004-11-18 at 02:08, David Brown wrote:
> Statistics were run on each table before query execution. The random page
> cost was lowered to 2, but as you can see, the estimated costs are wild
> anyway.
>
> As a comparison, MS SQL Server took less than 15 seconds, or 4 times faster.
>
> My
Josh Berkus wrote:
in March there was an interesting discussion on the list with the
subject "postgres eating CPU on HP9000".
Link, please?
http://archives.postgresql.org/pgsql-performance/2004-03/msg00380.php
---(end of broadcast)---
TIP
> >>in March there was an interesting discussion on the list with the
> >>subject "postgres eating CPU on HP9000".
Aha, this one. Yeah, I believe that they upgraded to 7.4 inorder to deal
with REINDEX issues.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> in March there was an interesting discussion on the list with the
> subject "postgres eating CPU on HP9000".
>http://archives.postgresql.org/pgsql-performance/2004-03/msg00380.php
Reviewing that, the problem is most likely that (a) they didn't
On Wed, Nov 17, 2004 at 10:32:48PM +, Simon Riggs wrote:
> The main issue is that PostgreSQL's default histogram statistics setting
> is lower than other RDBMS. This means that it is less able to
> discriminate between cases such as yours that are close to the edge.
> This is a trade-off betwee
Jim,
> Is there still a good reason to have the histogram stats so low? Should
> the default be changed to more like 100 at this point?
Low overhead. This is actually a TODO for me for 8.1. I need to find some
test cases to set a differential level of histogram access for indexed
fields, so
>> I've seen cases where it seems the
>> planer doesn't think it'll be getting a unique value or a small set of
>> values even though stats indicates that it should be.
A test case exhibiting the problem would be helpful.
regards, tom lane
---(end
Josh Berkus wrote:
in March there was an interesting discussion on the list with the
subject "postgres eating CPU on HP9000".
http://archives.postgresql.org/pgsql-performance/2004-03/msg00380.php
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming
32 matches
Mail list logo
