I have talked to Tom today and he is willing to implement the
discussed method of doing fsync on every file modified
between checkpoints, and add unlink handling for open files for Win32.
Great news. I'm sure this will benefig Unix platforms as well, when
taking into account the discussions
Consider either a box with many different postgresql instances, or one
that run both postgresql and other software. Issuing sync() in that
sitaution will cause sync of a lot of data that probably doesn't need
syncing.
But it'd probably be a very good thing on a dedicated server, giving the
Ramanujam H S Iyengar [EMAIL PROTECTED] writes:
The optimizer has no need, ever, to find a relation by name; all it ever
sees are predigested relation OIDs. So you are not making a lot of
sense here. You certainly cannot assume that a search-path lookup is
appropriate for a relation that the
Dear patchers,
Sorry, wrong list:-(
--
Fabien.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Scott,
I like it. Would a multiplier be acceptable?
default_stats_index_multiplier = 10
Yeah, I thought about that, but a multiplier would be harder to manage for
most people.I mean, what if your default_stats are at 25 and you want
your index_stats at 40? PITA. Also, if you
Fabien COELHO [EMAIL PROTECTED] writes:
Please find attached my first attempt at providing a localisation
information on the client side for syntax errors in psql.
Localisation tends to mean something quite different around here.
I'd suggest renaming the function to something like
Fabien COELHO [EMAIL PROTECTED] writes:
The on line N bit seems just noise to me.
It depends.
I can see that it would be useful in a very large query. Perhaps
include it only when the query has more than N lines, for some N
like three to five or so?
Another possibility is to keep the cursor
Dear Tom,
The on line N bit seems just noise to me.
It depends.
I can see that it would be useful in a very large query. Perhaps
include it only when the query has more than N lines, for some N
like three to five or so?
Yes, I can do that.
Another possibility is to keep the cursor as
Dear Tom,
Please find attached my first attempt at providing a localisation
information on the client side for syntax errors in psql.
Localisation tends to mean something quite different around here. I'd
suggest renaming the function to something like ReportSyntaxErrorPosition.
Ok.
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Consider either a box with many different postgresql instances, or one
that run both postgresql and other software. Issuing sync() in that
sitaution will cause sync of a lot of data that probably doesn't need
syncing.
But it'd
Fabien COELHO [EMAIL PROTECTED] writes:
Another possibility is to keep the cursor as just ^, and bury the
line info in the query extract. For instance:
Well, I want to preserve space for the query extract, that's where the
context information is! If I put more information there, I'll have to
On Thu, 11 Mar 2004, Josh Berkus wrote:
Scott,
I like it. Would a multiplier be acceptable?
default_stats_index_multiplier = 10
Yeah, I thought about that, but a multiplier would be harder to manage for
most people.I mean, what if your default_stats are at 25 and you want
Hello,
the subject is obscure, so I will try to explain. I would like to
develop index based on text field (or tsvector stolen from tsearch2),
but containing different type (for example cstring, varchar,etc.) in
order to tokenize the original field. I would like to use postgresql
btree
David Smith [EMAIL PROTECTED] writes:
Should I forget about btrees and move to GIST,
Yes. There's no provision in the btree code for an index storage type
different from the column datatype.
regards, tom lane
---(end of
Scott,
But possible more error prone. If you crank up the default statistics to
50, but the index default is still 25... OTOH, you could always have the
setting of used for index default be whichever is greater... hmmm.
Well, I'm not 100% opposed to a multiplier. I'd like to take a poll
Greg Stark [EMAIL PROTECTED] writes:
I've seen some pretty severe damage caused by calling sync(2) on a loaded
system. The system in question was in the process of copying data to an NFS
mounted archival site. When the sync hit basically everything stopped until
the buffered network writes
Fabien COELHO wrote:
There is also a localisation issue here, as the translation of both
lines must match so that the alignment is kept. I thought that if it
is the very same word, the translation should be the same.
You can just indent with as many spaces. This is done in other places
as
Uytkownik Tom Lane napisa:
David Smith [EMAIL PROTECTED] writes:
Should I forget about btrees and move to GIST,
Yes. There's no provision in the btree code for an index storage type
different from the column datatype.
regards, tom lane
Thank You for reply.
Let us suppose, the we retain
Tom Lane [EMAIL PROTECTED] writes:
This seems, um, hard to believe. Did he shut down the standard syncer
daemon? I have never seen a Unix system that would allow more than
thirty seconds' worth of unwritten buffers to accumulate, and would not
care to use one if it existed.
Well it was
Josh Berkus [EMAIL PROTECTED] writes:
Well, I'm not 100% opposed to a multiplier. I'd like to take a poll of DBAs
to find out which they would find more accessable. But since most people
seem to be ignoring this thread, I'm not sure we'll get much response ...
Maybe you should ask on
Tom,
Maybe you should ask on -admin or -general. Personally I thought there
wasn't anything to say until someone did some experiments to show
whether an indexed-column differential is really worthwhile and what a
plausible default value would be. The idea sounds good in the abstract,
but
Dennis Bjorklund [EMAIL PROTECTED] writes:
In C one can set a signal handler to catch floating point exceptions
(SIGFPE). Without a handler you can get NaN and Infinity as the
result of mathematical operations.
Okay, I think this would be a reasonable set of behavior:
- define a new GUC
I combed the archives but could not find a discussion on this and am
amazed this hasn't been discussed.
My experience with Oracle (and now limited experience with Pg) is that
the major choke point in performance is not the CPU or read I/O, it is
the log performance of big update and select
If a transaction will do large updates or inserts, why don't we just log
the parsed statements in the WAL instead of the individual data blocks
UPDATE table SET col = random();
---(end of broadcast)---
TIP 2: you can get off all lists at once
Marty == Marty Scholes [EMAIL PROTECTED] writes:
Marty Why have I not seen this in any database?
Marty There must be a reason.
For ARIES-style systems, logging parsed statements (commonly called
logical logging) is not preferred compared to logging data items
(physical or physiological
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Thu, 11 Mar 2004, Neil Conway wrote:
So, what is the correct behavior: if you multiply two values and get a
result that exceeds the range of a float8, should you get
'Infinity'/'-Infinity', or an overflow error?
That's the issue and I think we
On Thursday 11 March 2004 14:17, Josh Berkus wrote:
Tom,
Maybe you should ask on -admin or -general. Personally I thought there
wasn't anything to say until someone did some experiments to show
whether an indexed-column differential is really worthwhile and what a
plausible default
Robert,
Do you plan on handeling primary key columns differently (since they are
likely to be unique and indexed) ?
The same as any other indexed column.
Also how will you handle column that are part of expressional indexes (where
foo is true for example) ?
See my original proposal.
Neil Conway [EMAIL PROTECTED] writes:
Okay, I think this would be a reasonable set of behavior:
- define a new GUC var that controls how exceptional floating
point values (NaN, inf, -inf) are handled.
- by default, we still raise an error when a floating point
operation
Marty Scholes [EMAIL PROTECTED] writes:
My experience with Oracle (and now limited experience with Pg) is that
the major choke point in performance is not the CPU or read I/O, it is
the log performance of big update and select statements.
If your load is primarily big update statements,
On Thu, Mar 11, 2004 at 03:14:10PM -0800, Josh Berkus wrote:
So far, only 4 people, total, have expressed opinons on the matter. I'm
throwing this on Hackers so that members of projects we will be hosting can
indicate whether they:
A) Favor www.postgresql.net
B) Favor www.pgfoundry.org
Josh Berkus [EMAIL PROTECTED] writes:
Also how will you handle column that are part of expressional indexes (where
foo is true for example) ?
See my original proposal. These columns will be ignored. Expressions have
their own stats.
Yeah, I see no particular need to increase the stats
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Thu, Mar 11, 2004 at 03:14:10PM -0800, Josh Berkus wrote:
A) Favor www.postgresql.net
B) Favor www.pgfoundry.org
C) Don't care as long as the porting is relatively painless.
I'm not crazy about the name pgfoundry, but otherwise I think it's
On Thu, Mar 11, 2004 at 07:01:47PM -0500, Tom Lane wrote:
Actually, proposal (A) does provide such a separation: notice that the
projects would go under *.postgresql.net, with the core database remaining
at *.postgresql.org. I am not sure if that will provoke confusion or
not, but I think I
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
Here's another idea: couldn't we have a subdomain for the projects, as in
project.forge.postgresql.org? Or would that be too long?
That would be okay with me ...
regards, tom lane
---(end of
Hi,
Please remind me again why the postmaster cannot close and open the log
file when it receives a SIGHUP (to re-read configuration)? This was
discussed before but I cannot remember if and why this was not possible
or if the arguments are still valid after -l was added.
If this was possible
Jeroen,
Here's another idea: couldn't we have a subdomain for the projects, as in
project.forge.postgresql.org? Or would that be too long?
Hmmm ... wouldn't that be rather awkward with the projects with longer names?
http://orapgsqlviews.foundry.postgresql.org
That's 39 characters, not
Tom Lane [EMAIL PROTECTED] writes:
That sounds okay. Also we might want to distinguish NaN from
Infinity --- I would expect most people to want zero-divide to
continue to get reported, for instance, even if they want to get
Infinity for overflow.
Yeah, good point.
This I disagree with. It
Tom Lane wrote:
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Thu, Mar 11, 2004 at 03:14:10PM -0800, Josh Berkus wrote:
A) Favor www.postgresql.net
B) Favor www.pgfoundry.org
C) Don't care as long as the porting is relatively painless.
I'm not crazy about the name
Please find attached my first attempt at providing a localisation
information on the client side for syntax errors in psql. Basically, one
function is added which takes care of the burden. I put a lot of
comments in the function to try make it clear what is going on.
It validates for me
I can see that and considered it.
The seed state would need to be saved, or any particular command that is
not reproducible would need to be exempted from this sort of logging.
Again, this would apply only to situations where a small SQL command
created huge changes.
Marty
Rod Taylor wrote:
On Thu, 2004-03-11 at 21:04, Marty Scholes wrote:
I can see that and considered it.
The seed state would need to be saved, or any particular command that is
not reproducible would need to be exempted from this sort of logging.
Again, this would apply only to situations where a small SQL
A major reason for this is that logical logs make recovery contingent
on being able to execute the parsed statements. This execution
might, however, not be possible if the system is itself not in a
consistent state .. as is normally the case during recovery.
I am not sure I follow you here.
If your load is primarily big update statements, maybe so...
It is. Maybe we are anomalous here.
I don't think I buy that claim. We don't normally fsync the log file
except at transaction commit (and read-only transactions
don't generate
any commit record, so they don't cause an fsync).
Anyway, it really doesn't matter. You're trying to save a large amount
of time that simply isn't spent in this area in PostgreSQL. fsync()
happens once with commit -- and on a busy system, a single fsync call
may be sufficient for a number of parallel backends.
I think you may be right. I
On Mar 12, 2004, at 9:07 AM, Jeroen T. Vermeulen wrote:
On Thu, Mar 11, 2004 at 07:01:47PM -0500, Tom Lane wrote:
Actually, proposal (A) does provide such a separation: notice that the
projects would go under *.postgresql.net, with the core database
remaining
at *.postgresql.org. I am not sure
(Just a note: my comments are not pg-specific .. indeed I don't know
much about pg recovery).
Marty == Marty Scholes [EMAIL PROTECTED] writes:
Marty If the DB state cannot be put back to a consistent state
Marty prior to a SQL statement in the log, then NO amount of
Marty logging
The point is that with redo logging, you can just blindly apply the
log to the data pages in question, without even really restarting the
database.
I also am not a recovery expert, but I have watched it happen more than
once.
You bring up a good point. My (perhaps false) understanding with
Bruce Momjian [EMAIL PROTECTED] writes:
Another idea is whether a foreign key column should get extra
statistics?
In practice, both ends of an FK relationship have to be indexed,
so I don't see that we need any extra special case for that.
regards, tom lane
On Thu, 11 Mar 2004, Tom Lane wrote:
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
Here's another idea: couldn't we have a subdomain for the projects, as in
project.forge.postgresql.org? Or would that be too long?
That would be okay with me ...
I'd go for too long myself ...
Marc
Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
(Just a note: my comments are not pg-specific .. indeed I don't know
much about pg recovery).
...
BTW, logging raw datafile blocks would be pretty gross (physical
logging) and so ARIES logs the changes to each tuple in logical
fashion .. so if
On Thu, 11 Mar 2004, Gavin M. Roy wrote:
I think having a pgfoundry.postgresql.net/org is good, but it should
have its own identity, pgfoundry.org for the main url gets my vote for
what it's worth.
I like the shortness myself ...
IMHO, the domain name isn't the make/break of whether going to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Another idea is whether a foreign key column should get extra
statistics?
In practice, both ends of an FK relationship have to be indexed,
so I don't see that we need any extra special case for that.
Do they? We don't create an
Bruce,
Do they? We don't create an index automatically when using REFERENCES.
We do create an index for PRIMARY KEY.
I was just wondering if the REFERENCES column is more sensitive to join
usage and would benefit from more accurate statistics even if it doesn't
have an index.
I don't
IMHO, the domain name isn't the make/break of whether going to GForge will
succeed ... the success will be a matter of marketing it, and making sure
that its project are well known ... personally, focusing on the domain is
like focusing on the name of a car when you buy it, not on its features
Dear Tom,
Well, I want to preserve space for the query extract, that's where the
context information is! If I put more information there, I'll have to
reduce the extract length.
But in the form you are using, you have to reserve that space anyway.
Consider an error marker at the end of
56 matches
Mail list logo
