> On Feb 11, 2016, at 4:41 PM, Dan Langille <d...@langille.org> wrote:
>
>> On Feb 10, 2016, at 5:13 AM, Dan Langille <d...@langille.org> wrote:
>>
>>> On Feb 10, 2016, at 2:47 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
>>>
>>>
> On Feb 13, 2016, at 10:43 AM, Dan Langille <d...@langille.org> wrote:
>
> Today I tackled the production server. After discussion on the Bacula devel
> mailing list (http://marc.info/?l=bacula-devel=145537742804482=2
> <http://marc.info/?l=bacula-devel=14553774280
> On Feb 10, 2016, at 5:13 AM, Dan Langille <d...@langille.org> wrote:
>
>> On Feb 10, 2016, at 2:47 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
>>
>> On Tue, Feb 9, 2016 at 4:09 PM, Dan Langille <d...@langille.org> wrote:
>>> I have a wee
> On Feb 10, 2016, at 2:47 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
>
> On Tue, Feb 9, 2016 at 4:09 PM, Dan Langille <d...@langille.org> wrote:
>> I have a wee database server which regularly tries to insert 1.5 million or
>> even 15 million new rows into a
s.
https://gist.github.com/dlangille/1a8c8cc62fa13b9f
<https://gist.github.com/dlangille/1a8c8cc62fa13b9f>
I'm tempted to move it to faster hardware, but in case I've missed something
basic...
Thank you.
--
Dan Langille - BSDCan / PGCon
d...@langille.org
signature.asc
De
. That got me thinking: consider ZFS and HDD with volatile cache.
Do the characteristics of ZFS avoid this issue entirely?
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
-BEGIN PGP SIGNATURE
manager address, so I am addressing this complaint to
the whole list. Is there someone here who can fix the problem?
This one seems to have made it.
Rest assured, nobody is interested enough to censor anything here.
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org
, the checkpoints can't have very
much work to do, so their impact on performance is smaller. Once
you've got a couple of hundred MB on there, the per-checkpoint
overhead can be considerable.
Ahh bugger, I've just trashed my test setup.
Pardon? How did you do that?
--
Dan Langille
http
Erik Jones wrote:
On Feb 15, 2008, at 3:55 PM, Dan Langille wrote:
We're using PostgreSQL 8.1.11 on AIX 5.3 and we've been doing some
playing around
with various settings. So far, we've (I say we, but it's another guy
doing the work) found
that open_datasync seems better than fsync. By how
this behaviour?
FYI, 8.3.0 is not an option for us in the short term.
What have you been using on AIX and why?
thanks
--
Dan Langille -- http://www.langille.org/
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
design for encrypted function
bodies.
I keep thinking the problem of keys is similar that of Apache servers
which use certificates that require passphrases. When the server is
started, the passphrase is entered on the command line.
--
Dan Langille - http://www.langille.org
on in the background.
--
Dan Langille - http://www.langille.org/
Available for hire: http://www.freebsddiary.org/dan_langille.php
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
could experience performance improvement only by updating.
There are other benefits from upgrading, but you may be able to solve
this problem without upgrading.
--
Dan Langille - http://www.langille.org/
Available for hire: http://www.freebsddiary.org/dan_langille.php
On 23 Aug 2006 at 13:31, Chris wrote:
Dan Langille wrote:
I'm using PostgreSQL 8.1.4 and I'm trying to force the planner to use
an index. With the index, I get executions times of 0.5 seconds.
Without, it's closer to 2.5 seconds.
Compare these two sets of results (also provided
On 23 Aug 2006 at 22:30, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
Without leaving enable_hashjoin = false, can you suggest a way to
force the index usage?
Have you tried reducing random_page_cost?
Yes. No effect.
FYI, 8.2 should be a bit better about this.
Good
,
P.latest_link
FROM categories C, ports P JOIN element E on P.element_id = E.id
WHERE P.status = 'D'
AND P.category_id = C.id;
--
Dan Langille : Software Developer looking for work
my resume: http://www.freebsddiary.org/dan_langille.php
---(end of broadcast
On 20 Jan 2005 at 9:34, Ragnar Hafstað wrote:
On Wed, 2005-01-19 at 20:37 -0500, Dan Langille wrote:
Hi folks,
Running on 7.4.2, recently vacuum analysed the three tables in
question.
The query plan in question changes dramatically when a WHERE clause
changes from ports.broken
On 20 Jan 2005 at 6:14, Stephan Szabo wrote:
On Wed, 19 Jan 2005, Dan Langille wrote:
Hi folks,
Running on 7.4.2, recently vacuum analysed the three tables in
question.
The query plan in question changes dramatically when a WHERE clause
changes from ports.broken
On 20 Jan 2005 at 7:26, Stephan Szabo wrote:
On Thu, 20 Jan 2005, Dan Langille wrote:
On 20 Jan 2005 at 6:14, Stephan Szabo wrote:
On Wed, 19 Jan 2005, Dan Langille wrote:
Hi folks,
Running on 7.4.2, recently vacuum analysed the three tables in
question
On 21 Jan 2005 at 8:38, Russell Smith wrote:
On Fri, 21 Jan 2005 02:36 am, Dan Langille wrote:
On 20 Jan 2005 at 7:26, Stephan Szabo wrote:
[snip]
Honestly I expected it to be slower (which it was), but I figured
it's worth seeing what alternate plans it'll generate
(specifically
/paste/results/rV8khJ18.html
Any suggestions please?
--
Dan Langille : http://www.langille.org/
BSDCan - The Technical BSD Conference - http://www.bsdcan.org/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
of postgresql is 7.3.4(using RHDB from redhat)
*pg_autovacuum running at 12 and 24 hour each day
What do you mean by pg_autovacuum running at 12 and 24 hour each day?
I suspect he means at 1200 and 2400 each day (i.e noon and midnight).
--
Dan Langille - http://www.langille.org
the ports table is scanned in the
first place. Clues please?
--
Dan Langille : http://www.langille.org/
BSDCan - http://www.bsdcan.org/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
On 7 Jun 2004 at 16:00, Rod Taylor wrote:
On Mon, 2004-06-07 at 15:45, Dan Langille wrote:
A production system has had a query recently degrade in performance.
What once took 1s now takes over 1s. I have tracked down the
problem to a working example.
What changes have you made
On 7 Jun 2004 at 16:38, Rod Taylor wrote:
On Mon, 2004-06-07 at 16:12, Dan Langille wrote:
On 7 Jun 2004 at 16:00, Rod Taylor wrote:
On Mon, 2004-06-07 at 15:45, Dan Langille wrote:
A production system has had a query recently degrade in performance.
What once took 1s now
On 7 Jun 2004 at 16:38, Rod Taylor wrote:
On Mon, 2004-06-07 at 16:12, Dan Langille wrote:
I grep'd postgresql.conf:
#effective_cache_size = 1000# typically 8KB each
#random_page_cost = 4 # units are one sequential page fetch cost
This would be the issue. You haven't
On 7 Jun 2004 at 18:49, Dan Langille wrote:
On 7 Jun 2004 at 16:38, Rod Taylor wrote:
* random_page_cost (good disks will bring this down to a 2 from a
4)
I've got mine set at 4. Increasing it to 6 gave me a 1971ms query.
At 3, it was a 995ms. Setting it to 2 gave me
27 matches
Mail list logo
