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
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
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
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
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
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
logging
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 little more about
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?
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
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 the
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'm not sure I
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 first
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.
What do you
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
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.
Doesn't that
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
