On Wednesday 25 June 2008 11:24:23 Greg Smith wrote:
> What I often do is get a hardware RAID controller, just to accelerate disk
> writes, but configure it in JBOD mode and use Linux or other software RAID
> on that platform.
>
JBOD + RAIDZ2 FTW ;-)
--
Robert Treat
Build A B
ht I would post to
see if anyone had any thoughts on it. (If there is some additional info I can
provide, please lmk).
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Saturday 26 April 2008 13:26, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Friday 25 April 2008 17:32, Tom Lane wrote:
> >> Robert Treat <[EMAIL PROTECTED]> writes:
> >>> Oddly some dtrace profiling gave me this, which is pretty d
On Friday 25 April 2008 17:32, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Oddly some dtrace profiling gave me this, which is pretty different, but
> > certainly doesn't have concerns about TransactionIdIsCurrentTransactionId
>
> which s
On Monday 21 April 2008 12:54, Alvaro Herrera wrote:
> Robert Treat wrote:
> > Unfortunatly I don't have the 8.1 system to bang on anymore for this,
> > (though anecdotaly speaking, I never saw this behavior in 8.1) however I
> > do now have a parallel 8.3 system cru
On Thursday 27 March 2008 17:11, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Sunday 16 March 2008 22:18, Tom Lane wrote:
> > > > > Fix TransactionIdIsCurrentTransactionId() to use binary
> > > > > search instead
> > >
On Thursday 06 December 2007 04:38, Simon Riggs wrote:
> Robert,
>
> On Wed, 2007-12-05 at 15:07 -0500, Robert Treat wrote:
> > If the whole performance of your system depends upon indexed access, then
> > maybe you need a database that gives you a way to force index access a
without a LIMIT
> - Setting it at 100 million is going to prevent unconstrained product
> joins etc..
I think you're completly overlooking the effect of disk latency has on query
times. We run queries all the time that can vary from 4 hours to 12 hours in
time based solely on the amount of concurrent load on the system, even though
they always plan with the same cost.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Sunday 02 December 2007 15:26, Usama Munir Dar wrote:
> Robert Treat wrote:
> > On Wednesday 28 November 2007 11:20, Usama Munir Dar wrote:
> >> EnterpriseDB (www.enterprisedb.com), ofcourse
> >
> > lame :-P
>
> Have you or anyone you know tried the trainin
ommend them, but there are several
options, check out the training section on the website:
http://www.postgresql.org/about/eventarchive
Note also some of the more popular pg support companies also offer personal
training, even if it isn't advertised. HTH.
--
Robert Treat
Build A Brighter LAMP
oads to be able to do it.
>
> Who has built the biggest baddest Pg server out there and what do you
> use?
>
While I'm not sure this will be that much help, I'd feel remisce if I didn't
point you to it...
http://www.lethargy.org/~jesus/archives/66-Big-Bad-PostgreSQ
, I think you'd end most of the confusion, make
it easier to run concurrent servers and simplify the upgrade process for
source installs, and give other package maintiners a way to achive what
debian has. Maybe in PG 9...
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middlewar
> as batch.
>
> Would this really be important? I mean, would it affect a *comparison*??
> As long as he does it the same way for all the hardware setups, seems ok
> to me.
>
Sure. He looks i/o bound, and single inserts vs. batch inserts will skew
results even further depending
could make the
> update slower.
>
> Maybe it's the moment to change my question, is there any trick to get a
> table that can be modified/queried very fast and with the minimum of
> overhead? This table will have several queries every second and I
On Tuesday 17 October 2006 22:55, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > When it happens it tends to look something like this:
> > http://archives.postgresql.org/pgsql-performance/2006-01/msg00154.php
> >
> > Funny that for all the pe
>> > Can you think of any others?
>
> -- Incorrect estimate for result of DISTINCT or GROUP BY.
Yeah, that one is bad. I also ran into one the other day where the planner
did not seem to understand the distinctness of a columns values across table
p
mance/2006-01/msg00154.php
Funny that for all the people who claim that improving the planner should be
the primary goal that no one ever took interest in the above case.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
rdf reports, or export the erd as a
graphic. Downside is it can't do direct port to pdf (though you could
get around that with OO i imagine), plus its windows only and
commercial.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
-
stimate at the nested loop stage, but it does seem
to have a better understanding of the # of rows it will return in the
index scan on msg307. This leads me to wonder if there something I could
do to improve the estimates on the 8.1 machine?
Robert Treat
--
Build A Brighter Lam
00..111.75 rows=25752 width=0) (actual time=4.271..4.271 rows=25542
loops=1)
-> Hash (cost=55.95..55.95 rows=1695 width=8)
(actual time=5.663..5.663 rows=1695 loops=1)
-> Seq Scan on myapp_app ia
(cost=0.00..55.95 rows=1695 width=8) (actual time=0.006..
time=0.005..2.850 rows=1695
loops=1)
-> Sort (cost=4030.42..4095.99 rows=26230 width=20) (actual
time=250.434..286.311 rows=25542 loops=1)
Sort Key: public.msg306u.rmsbinaryid,
public.msg306u.msgid, public.msg306u.entityid
reindex should be faster, since you're not dumping/reloading the table
contents on top of rebuilding the index, you're just rebuilding the
index.
Robert Treat
emdeon Practice Services
Alachua, Florida
On Wed, 2005-10-12 at 13:32, Steve Poe wrote:
>
> Would it not be faster to
e we
know that they are dead to any and all other transactions currently going on.
This would save you from having to vacuum to get the tuples marked ready for
reuse. In the above scenario this could be a win, whether it would be
overall is hard to say.
--
Robert Treat
Build A Brighter Lamp ::
/docs/8.0/interactive/sql-keywords-appendix.html
Robert Treat
On Mon, 2005-03-14 at 03:55, Christopher Kings-Lynne wrote:
> You will still need to use double quotes in 8.0.1...
>
> Chris
>
> Gourish Singbal wrote:
> > Thanks a lot,
> >
> > we might be upgrading to 8.0
to hold all of the pages you use in a day... this is hard to calculate
in 7.3, but if you look at your vacuum output and add the number of pages
cleaned up for all tables, this could give you a good number to work with. It
would certainly tell you if your setting is too small.
--
Robe
ll, and dont forget the sequences. easiest way i
found was to generate the list programatically around a select * from
pg_class with appropriate where clause to get just the desired tables.
> Do I need to change any of the other scripts file in the example?
>
Chances are yes, since tho
mail_data"
> INFO: "cdm_email_data": 65869 pages, 3000 rows sampled, 392333 estimated
> total rows
>
> #After vacuum full(s)
> mdc_oz=# select count(*) from cdm.cdm_email_data;
> count
> -
> 5433358
> (1 row)
>
I do think the count(*) s
0f1PaalTlE/0.0.9.1.0.6.13.0.3.1.3.0.7.12.1.1.0
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
to
> from techdocs.
Done. :-)
>
> If you could identify candidate keys on a view, you could conceivably automate
> the process even more. That's got to be possible in some cases, but I'm not
> sure how difficult it is to do in all cases.
>
it seems somewhere be
hat the queries
inside the function will work like an implicit transaction.
Robert Treat
On Thu, 2004-06-03 at 17:38, Marcus Whitney wrote:
> Am I on the wrong list to ask this question, or does this list usually have
> low activity? Just asking because I am new and I need to know where to
attnum and relname = 'mytable' to see the current
statistics on the table, but its not timestamped.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore yo
nts... what version of postgresql is this?
Try reindexing i_bookgenres_genre_id and capture the explain analyze for
that. If it doesn't help try doing set enable_indexscan = false and
capture the explain analyze for that.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware}
#x27;ll notice any difference in
performance against running the query with no bi, it's dependent on a
number of factors really.
Oh, and as the other poster alluded to, knock down your shared buffers
by about 50% and see where that gets you. I might also knock *up* your
effective cac
On Tue, 2004-04-13 at 15:18, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> Well, the first problem is why is ANALYZE's estimate of the total row
> count so bad :-( ? I suspect you are running into the situation where
> the initial pages of the table are thinl
00
ERROR: column "msg" of relation "data_pull" does not exist
transform=# select version();
version
----
PostgreSQL 7.4beta4 on i686-pc-linux-gnu, com
loops=1)
Filter: ((age >= 18) AND (age <= 24) AND (gender = 'm'::bpchar))
Total runtime: 8138.607 ms
(17 rows)
so i guess i am wondering if there is something I should be doing to
help get the better plan at the more accurate stats levels and/or
which has a slew of
links/articles/tutorials regarding development and administration of
postgresql databases (including a link to Scott's aforementioned doc)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)
had posted yet another version after
ours... and in fact the one posted is not exactly what I use now either :-)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
duction environment.
You cut me deep there Josh, real deep. :-)
If you search the pgsql-sql archives you'll find some helpful threads on using
nested sets in PostgreSQL, one in particular I was involved with was a
generic "move_tree" function that enabled moving a node from one
for a more detailed explanation:
http://www.postgresql.org/docs/7.4/interactive/runtime-config.html#RUNTIME-CONFIG-RESOURCE
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Wed, 2004-02-25 at 03:19, Jonathan M. Gardner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm not sure if my original reply made it through. Ignore the last one if
> it did.
But I liked the last one :-)
>
> On Tuesday 24 February 2004 1:48 pm,
ommunity has gone
> head-to-head on your own application?
>
We have the setup to do informal benchmarking via OSDL, but afaik mysql
doesn't conform to any of the dbt benchmarks...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
results, retrieved via a query with a "LIMIT
> " clause, so $pg_numrows is m.
> And retrieving all results (i.e. no LIMIT) is at least as expensive as
> COUNT(*).
>
Depending on frequency of updates and need for real time info, you could
cache the count in session as long as
nt enough for that statistics to be updated all
> the time or run autovacuum daemon..
>
> Ran into same problem on my machine till I remembered about vacuum..:-)
>
Actually you only need to run analyze to update the statistics.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache
yze show for the insert query?
Are there FK and/or Indexes involved here? Did you you reindex?
A vacuum verbose could give you a good indication if you need to reindex,
compare the # of pages in the index with the # in the table.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} Pos
ng if there will be any noticeable impact.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
z.state = 'WA'
> ORDER BY date_time;
>
This wont completely solve your problem, but z.state = 'WA' would seem
to be mutually exclusive of the != AA|AE|AP. While it's not much, it is
extra overhead there doesn't seem to be any need for...
Robe
override percentage or the default percentages based on
rel_tuples (or rel_pages). This would give autovacuum a place to look
for each table as to when it should vacuum, and gives administrators the
option to tweak it on a per table basis if they find they need a
specific table to vacuum at a differ
On Thu, 2003-11-13 at 12:00, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Does the not exist query produce worse results in 7.4 than it did in
> > 7.3?
>
> EXISTS should work the same as before.
>
right. the original poster is asking if there
?
Robert Treat
On Thu, 2003-11-13 at 02:53, Rajesh Kumar Mallah wrote:
>
> Hi,
>
> NOT EXISTS is taking almost double time than NOT IN .
> I know IN has been optimised in 7.4 but is anything
> wrong with the NOT EXISTS?
>
> I have vaccumed , analyze and run the query many
en pg_dump is running, that is
also cpu intensive, so we end up with two highly cpu intensive items
running on our machine, and we start to notice issues on the main web
system.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
't be used in place of the second
one if i were to delete the second one. its a heavily updated table, so
axing the second one would be a bonus for performance, am i missing
something? Thanks in advance,
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware}
obably not your best option
to talk to on PRHE... While there are Red Hat employees floating around
these lists, I'd first suggest reading over the website and then either
emailing the PRHE lists or one of it's team members depending on the
specifics of any questions.
Robert Treat
--
e Solutions
> San Francisco
>
>
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
t;
> > You know you have to restart the postmaster to make those changes take
> > effect, right?
> Yup. I still see no effect after restart.
>
Given that you knew of no way to determine how much free space map you
were using, what is your criteria for it to "appear to be wor
y day to watch for
these types of posts.
> One last observation: someone looking at both databases, reading those
> posts, might get a bad impression of Postgres based on the inconsistency
> and incorrectness of some of the statements made about MySQL. If a
> salesperson provides misinfo
On Wed, 2003-09-24 at 17:57, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > In .conf file I have default checkpoints set to 3, but I noticed that in
> > my pg_xlog directory I always seem to have at least 8 log files. Since
> > this is more than the su
n the default number
anyways... I've always treated wal logs as self maintaining, am I over
analyzing this?
Another thought popped into my head, is it just coincidence that I
always seem to have 8 files and that wal_buffers defaults to 8? Seems
like it's not but I love a good conspiracy the
crashes in
the middle of reload i'm pretty sure i'd be starting all over anyway...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Fri, 2003-08-22 at 16:54, Tomka Gergely wrote:
> 2003-08-22 ragyogó napján Robert Treat ezt üzente:
>
> > On Thu, 2003-08-21 at 14:16, Bill Moran wrote:
> > > >>>What test are interesting? Plese give us tips and ideas. The guy has time
> > > >>>f
performs well enough I could see a recommendation for it for those
who are willing to look beyond linux.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
dedicated database for a webserver would be tuned
differently from a server that was running both the webserver and the database on
the same machine.
Robert Treat
--
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
7.0 would be as
effective as an upgrade, after setting your shared buffers up, I'd put
your efforts into upgrading. (Note Beta test for 7.4 starts in 2 weeks)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
63 matches
Mail list logo
