> On Feb 13, 2016, at 10:43 AM, Dan Langille wrote:
>
> Today I tackled the production server. After discussion on the Bacula devel
> mailing list (http://marc.info/?l=bacula-devel&m=145537742804482&w=2
> <http://marc.info/?l=bacula-devel&m=145537742804482&w
> On Feb 11, 2016, at 4:41 PM, Dan Langille wrote:
>
>> On Feb 10, 2016, at 5:13 AM, Dan Langille wrote:
>>
>>> On Feb 10, 2016, at 2:47 AM, Jeff Janes wrote:
>>>
>>> On Tue, Feb 9, 2016 at 4:09 PM, Dan Langille wrote:
>>>> I have
> On Feb 10, 2016, at 5:13 AM, Dan Langille wrote:
>
>> On Feb 10, 2016, at 2:47 AM, Jeff Janes wrote:
>>
>> On Tue, Feb 9, 2016 at 4:09 PM, Dan Langille wrote:
>>> I have a wee database server which regularly tries to insert 1.5 million or
>>> even
> On Feb 10, 2016, at 2:47 AM, Jeff Janes wrote:
>
> On Tue, Feb 9, 2016 at 4:09 PM, Dan Langille wrote:
>> I have a wee database server which regularly tries to insert 1.5 million or
>> even 15 million new rows into a 400 million row table. Sometimes these
>> ins
itions.
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
s
lsar_ssd/
>
> I have updated our documentation to mention that even SSD drives often
> have volatile write-back caches. Patch attached and applied.
Hmmm. That got me thinking: consider ZFS and HDD with volatile cache.
Do the characteristics of ZFS avoid this issue entirely?
- --
Dan Langi
> publicised list 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
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?
--
Da
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
Have you seen 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
her than endless arguments to happen,
come up with a nice key-management 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
e more to that original table. What about triggers?
rules? Perhaps there other things going 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
nfirmed via explain (or explain analyse) that the index is
being used?
> So I'm asking me if it is useful to update to the actual 8.2 version
> and if we could experience performance improvement only by updating.
There are other benefits from upgrading, but you may be able to
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
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.
> >
&
act_suffix,
P.homepage,
P.status,
P.broken,
P.forbidden,
P.ignore,
P.restricted,
P.deprecated,
P.no_cdrom,
P.expiration_date,
P.latest_link
FROM categories C, ports P JOIN element E on P.element_id = E.id
WHERE P.status = 'D'
A
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 seei
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,
> > > >
> >
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
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 dramatical
b.net/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?
tion).
> >cpu look like not running very hard
> >
> >*php is not running on the same machine
> >*redhat enterprise 3.0 ES
> >*the version of postgresql is 7.3.4(using RHDB from redhat)
> >*pg_autovacuum running at 12 and 24 hour each day
> >
> >
&g
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
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
&
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
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.
&g
erstand is why 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 appropria
27 matches
Mail list logo
