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 Brighter LAMP :: Linux
something specific to hash
joins. I'll note that this is the behavior I recall from 8.2, so I'm not sure
if this is a bug, or just an outright deficiancy, but thought 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
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 seems to pretty much destroy your thesis
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 different,
but certainly doesn't have concerns about
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 crunching the data, and it is showing
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
of linear search when checking child-transaction XIDs
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 at
the query level
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 training offerings? or you think
its lame because i top
:
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 :: Linux Apache {middleware} PostgreSQL
---(end of broadcast
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-PostgreSQL.html
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware
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 {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: don't forget
-Implementing-a-queue-in-SQL-Postgres-version.html
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
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
the other day where the planner
did not seem to understand the distinctness of a columns values across table
partitions...
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: In versions below
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
---(end of broadcast
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 Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6
explain why it is choosing the initial slower plan
and/or how to get it to run something closer to the second faster plan?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze
of the columns
but that didn't help, though maybe I was raising it on the right
columns.. any suggestions there? Or perhaps a better way to write the
query... I'm open to suggestions. TIA,
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end
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 do a dump/reload
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 :: Linux Apache {middleware} PostgreSQL
---(end of broadcast
-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.1 soon.. till than using double quotes
should be fine.
regards
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.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
are yes, since those scripts were written for the example scenario
provided, and your environment is sure to be different. Again, post to the
slony mailing lists if you need more help.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end
in the way or your not giving
us a complete copy/paste of the session involved.
--
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
. 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 between Joe Conways work work arrays and polymorphic
functions in 7.4 this should be feasible.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
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 ask
this question
runtime: 7875.000 ms
A question and two experiments... 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
. I might also knock *up* your
effective cache size... try doubling that and see how things go.
Hope this helps... and others jump in with corrections if needed.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast
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 thinly populated and ANALYZE
seem to push it back to the original plan).
alternatively if anyone has any general suggestions on speeding up the
query I'd be open to that too :-)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast
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 branch to
another.
Robert Treat
--
Build A Brighter Lamp
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]
is that sort_mem controls how much memory a given query is
allowed to use before spilling to disk, but it will not grab that much
memory if it doesn't need it.
See the docs for a more detailed explanation:
http://www.postgresql.org/docs/7.4/interactive/runtime-config.html#RUNTIME-CONFIG-RESOURCE
Robert Treat
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, Robert Treat wrote:
On Tue, 2004
-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
---(end of broadcast
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 the user stays within the given
piece of your app.
Robert Treat
analyze to update the statistics.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
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
, 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...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast
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 different rate than the standard.
Robert Treat
--
Build
web
system.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
?
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 times
still not in is faster than
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 is something wrong with
exist based
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} PostgreSQL
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
for it to appear to be working? If
it's that space keeps growing, then your probably not vacuuming
frequently enough.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive
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 suggested 7, I'm wondering if this means
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 theory.
Robert Treat
--
Build
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
:)
Well, I suppose ...
Well I'm not a hardcore bsd fighter and I'd like to see how it stacks up
as well. UFS+softupdates is supposed to be a very safe combination, if
it performs well enough I could see a recommendation for it for those
who are willing to look beyond linux.
Robert Treat
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
for other test.
It's a shame you didn't test ufs
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
53 matches
Mail list logo
