Hi all!
I know this is OT, sorry for that.
I just wanted you to know that I've read this thread and welcome any and all
help in order to get Npgsql in best shape as possible.
As pointed out by Robert, join us on Npgsql Forums so we can discuss. This
would be very nice!
I also agree with Br
Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
I found it confusing to when setting it to 0 *enabled* logging so I imagine
others will be as well. Also it seems we may want to have other messages
logged from autovacuum so it would be better to leave room for other
log_aut
Gregory Stark wrote:
>
> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
Sure, whatever makes the most sense. In fact min_duration would be more
consistent.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"El día que dejes de cambiar d
Hi.
Yeah, We have released Ver2.0 now. However, It is MS-VisualStudio and
somewhat difficult. Then, Some change of ADO2.0(.NET2.0)...
we want to clear a problem. However, It seems that very much time is
required one by one. There is many expectations. :-)
Regards,
Hiroshi Saito
- Original M
Frank Wiles wrote:
ActiveState Perl is threaded and DBD::Pg works just fine with it. In
fact, you don't need to build your own - just get the one from
pgfoundry:
And I've been using a threaded Perl on Linux/BSD systems for
years. In fact, unless someone recompiles Perl every Fedo
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
> Sure, whatever makes the most sense. In fact min_duration would be more
> consistent.
I'm not sure I believe Greg's argument about needing more autovac
l
On Thu, 02 Aug 2007 18:19:36 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Brar Piening wrote:
> > Robert Treat schrieb:
> >> That would be nice. Of course none of this seems relevant to
> >> hackers, so I'd
> > Your'e right - of course.
> >
> > But sometimes I wish 'hackers' would care a l
Actually, we happen to be running into a situation here where we need more
logging. We need to understand why autovacuum isn't considering logging this
table:
relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan |
idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup |
"pg_ctl stop" seems to be causing a fast stop today. Anybody remember
touching logic that might affect that?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archi
Tom Lane wrote:
"pg_ctl stop" seems to be causing a fast stop today. Anybody remember
touching logic that might affect that?
What's the evidence for that? I can't see any on the buildfarm.
cheers
andrew
---(end of broadcast)
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "pg_ctl stop" seems to be causing a fast stop today.
> What's the evidence for that? I can't see any on the buildfarm.
I don't think the buildfarm does anything that would prove it one way or
the other. But I find that if I start th
On Fri, 2007-08-03 at 12:38 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Gregory Stark wrote:
> >> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
>
> > Sure, whatever makes the most sense. In fact min_duration would be more
> > consistent.
>
>
I wrote:
> Once the postmaster has been up for a little bit this seems not to happen
> anymore, which means it could have been that way for awhile without
> anyone noticing. I'm not sure yet how long is "a little bit" --- seems
> to be more than a minute, which destroys my first theory that the fi
On Thu, 2007-08-02 at 12:50 -0400, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Tom,
> >> I don't actually think that what Jignesh is testing is a particularly
> >> realistic scenario, and so I object to making performance decisions on
> >> the strength of that one measurement.
>
On Fri, 2007-08-03 at 18:56 +0100, Gregory Stark wrote:
> Actually, we happen to be running into a situation here where we need more
> logging. We need to understand why autovacuum isn't considering logging this
> table:
>
> relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan |
On Aug 3, 2007, at 14:59 , Simon Riggs wrote:
On Fri, 2007-08-03 at 12:38 -0400, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Gregory Stark wrote:
Could I suggest renaming log_autovacuum to
log_autovacuum_min_duration?
Sure, whatever makes the most sense. In fact min_durati
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-08-02 at 12:50 -0400, Tom Lane wrote:
>> Also, you should not imagine that boosting NUM_CLOG_BUFFERS has zero
>> cost. The linear searches used in slru.c start to look pretty
>> questionable if we want more than a couple dozen buffers.
> Do
Tom,
> In any case this is getting pretty darn far away from a one-liner patch.
> I think it needs more thought and more testing than we can spare now.
I'm still hoping that we can show that a moderate increase (say 24 or 32)
has no noticeable effect on other workloads. Haven't had time to run
PostgreSQL has the oldest community of coders, and PostgreSQL itself is the
oldest product. Still its performance (in some areas) and GUI does not match
MySQL. MySQL .NET Driver gives very good performance for the MySQL Database,
FireBird .NET Driver gives performance for FireBird.
Not only it is
19 matches
Mail list logo
