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
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
and/
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'
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 crea
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
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
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
> > ".forge.postgresql.org"? Or would that be too long?
>
> That would be okay with me ...
I'd go for "too long" myself ...
---
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
> 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
(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
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 i
> 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
> 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
> 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 h
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
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:
I
> 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
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 pgfoun
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 wit
Jeroen,
> > Here's another idea: couldn't we have a subdomain for the projects, as in
> > ".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 incl
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 T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Here's another idea: couldn't we have a subdomain for the projects, as in
> ".forge.postgresql.org"? Or would that be too long?
That would be okay with me ...
regards, tom lane
---(end of broadca
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 thi
"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 th
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 st
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.pgfound
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,
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
> oper
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.
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 def
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 th
> "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
> 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 onc
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 stat
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 G
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,
> b
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 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 w
Użytkownik 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 retai
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
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 write
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 po
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 broadcast)-
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 impleme
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 wa
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'l
"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.
> > Bu
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.
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 th
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 c
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 Report
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 want
> 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])
"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 relati
> 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
> 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 discussion
56 matches
Mail list logo
