supporting them.
It's helpful to me. Any feedback is appreciated. If you
did want to consider including it, let me know what to clean
up. If not, I thought I'd just put it here if anyone else finds
it useful too.
Thanks for your time,
Ron Mayer
Longer:
(A) What
Tom wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Compared to the ISO 8601 time interval specification, the
postgresql interval syntax is quite verbose. For example:
Postgresql interval: ISO8601 Interval
: What's the best inexpenive way for me to know if this changed
at all between the final draft and the published standard?
Ron Mayer said:
This patch allows ISO 8601 time intervals using the format
with time-unit designators to specify postgresql intervals.
...
Much more info can
Tom wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Tom wrote:
Er, don't we support that already?
...AFAICT, doesn't match ISO 8601...
Well, it's *supposed* to match ISO Unless ISO has put out
multiple specs that cover this?
Any way to tell if this is the case.
8601's the one I see
I have a working output-part (attached below, but I'm
still cleaning up the documentation so I'll submit another
one later)
Ugh. Something in this pc quoted some characters in the attachment.
Rather than trying to apply it, wait a couple days and I'll submit
an update where the docs
On Sat, 20 Dec 2003, Bruce Momjian wrote:
Tom Lane wrote:
This is a horrid, horrid idea. Datestyle is already a complete mess
...
Please revert that part of the patch and instead invent a new GUC
variable that's specifically for interval formatting.
OK, I have backed out the patch. [...]
Short summary:
I find this tiny (9-line) patch useful to help my clients know
when FSM settings may need updating.
Some of the more frequently asked questions here are in regards to FSM
settings. One hint I've seen is to run vacuum verbose;. At the end
of thousands of lines of INFO and
Thanks everyone for the feedback on my patch.
Objections I've heard (both online and in email) included:
* WARNING is too strong for possibly OK behavior
* It's similar to checkpoints occuring too frequently...
consider increasing...checkpoint_segments which
is a LOG
On Thu, 24 Feb 2005, Tom Lane wrote:
I preferred Simon's idea of not trying to produce a warning for pages
when we've detected relation overflow.
Sounds good. I'll make that update.
Should the relation overflow be a WARNING or a LOG? It sounds like
if you have that problem it's almost
On Thu, 24 Feb 2005, Ron Mayer wrote:
Should the relation overflow be a WARNING or a LOG? It sounds like
if you have that problem it's almost certainly a problem, right?
And while I'm at it... what's the convention for INFOs vs LOGs?
The checkpoint...too frequent seemed similar, and is a LOG
On Thu, 24 Feb 2005, Tom Lane wrote:
I'd go for making them both LOG, I think. More consistent.
Ok, here's another try :) With a couple more questions...
1. If I read Simon's email correctly, it implied that he wanted to see
the free space map message for a VACUUM even when VERBOSE is
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Should the relation overflow be a WARNING or a LOG? ...
I'd go for making them both LOG, I think. More consistent.
Can we also update this wording:
INFO: free space map: 52 relations, 61
.
---
Ron Mayer wrote:
On Sun, 27 Feb 2005, Simon Riggs wrote:
On Fri, 2005-02-25 at 16:48 -0800, Ron Mayer wrote:
Getting closer?
For me, yes. [...]
The not-warnings seem a little wordy for me, but they happen when and
how I would hope for.
So, for me, it looks like a polish of final wording
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I never heard any discussion on whether this should be backpatched to
8.0.X. Should it?
I personally think it should _not_ be backpatched. Since it
doesn't fix any bugs, it's not really the kind of thing I
would expect to be
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
is opening a file with O_DIRECT sufficient to ensure that
a write(2) does not return until the data has hit disk?
Some googling suggests so, eg
http://www.die.net/doc/linux/man/man2/open.2.html
Really? On that page I read:
David Fetter wrote:
On Thu, Jun 02, 2005 at 05:41:46PM +0200, Pavel Stehule wrote:
My next patch is implementation least and greatest functions. If
will possible I prefere contrib for it, but it's inpossible. ...
BTW, the thing about least() and greatest() (basically the row-wise
versions of
Tom Lane wrote:
Gene [EMAIL PROTECTED] writes:
I have a table that inserts lots of rows (million+ per day) int8 as primary
key, and I cluster by a timestamp which is approximately the timestamp of
the insert...
ISTM you should hardly need to worry about clustering that --- the data
will be
Heikki Linnakangas wrote:
Ron Mayer wrote:
In my case my biggest/slowest tables are clustered by zip-code (which
does a reasonable job at keeping counties/cities/etc on the
same pages too)
No deletes? If the tables grow over time, you probably would need to run
CLUSTER every now
Tom Lane wrote:
Florian Weimer [EMAIL PROTECTED] writes:
Have you tried switching to Adler32 instead of CRC32?
Is anything known about the error detection capabilities of Adler32?
There's a lot of math behind CRCs but AFAIR Adler's method is pretty
much ad-hoc.
As I understand it, it's
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Welcome to UI development. There is always *far* more argument of minor
matters of appearance than over anything else, in my experience.
Which is a good thing (in this case at least), because otherwise we
would end up with a crappy UI just because
20 matches
Mail list logo
