On Thu, 2002-05-23 at 15:20, Michael Meskes wrote:
On Wed, May 22, 2002 at 10:58:15AM -0700, Ulrich Drepper wrote:
On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2.5
(same as Red Hat 7.3's version).
This is
On Thu, May 23, 2002 at 09:29:06AM -0700, Ulrich Drepper wrote:
On Thu, 2002-05-23 at 07:20, Michael Meskes wrote:
The glibc version in the soon to be released Woody
release is 2.2.5.
The version in RHL7.3 is 2.2.5-34. This is not what Debian uses. Maybe
you should read the
...
But anybody using Unix dates as general dates has leaped into exactly the
same sort of trap that caused people to get so paranoid about Y2K.
Certainly true. We don't use Unix dates as general dates, we use the
Unix time zone database and API for dates and times within the year
range of
On Fri, 24 May 2002 06:10:39 PDT, the world broke into rejoicing as
Thomas Lockhart [EMAIL PROTECTED] said:
...
But anybody using Unix dates as general dates has leaped into exactly the
same sort of trap that caused people to get so paranoid about Y2K.
Certainly true. We don't use Unix
I just looked at Bruce's talk about PostgreSQL history and saw the
flowchart slide. This would probably give a good poster too. Do we have
this flowchart available as eps, gif, whatever?
Or Bruce, do you have a version that you could send me?
Thanks a lot.
Michael
--
Michael Meskes
[EMAIL
[EMAIL PROTECTED] writes:
By the way, the seemingly relevant link to look at for TZ info is
http://www.twinsun.com/tz/tz-link.htm, linking to the data used by
various Unix implementations.
Oh, this is interesting: it claims that
: This database (often called tz or zoneinfo) is used by
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 19, 2002 6:40 PM
To: Joel Burton
Cc: Joe Conway; Pgsql-Hackers@Postgresql. Org
Subject: Re: [HACKERS] Exposed function to find table in schema search
list?
Joel Burton [EMAIL PROTECTED] writes:
Is
Hello,
Can anyone help me how to add big amount of data into database?
I tried COPY, first the addition speed was good, but after each minute it
became worser and worser.
You can see the table illustrating this below.
There were ~10,000,000 records.
There were no indexes created on table.
Tom Lane wrote:
It seems to me that it'd be really practical to just take what we
need out of this distribution and forgo all dependency on
system-provided timezone databases. And, since there's a mailing
list maintaining it, we could expect someone else to handle updates
;-) ... we'd
Joel Burton [EMAIL PROTECTED] writes:
Well, sort of, but if we had been promoting a function tableoid(text)
returns oid, we wouldn't have to make any change for the move to regclass,
would we? I mean, it's specific to PG, but a simple wrapper might outlive
the next under-the-hood change.
I
Joe Conway [EMAIL PROTECTED] writes:
I don't understand precisely what need to be done, but I'll give it a
shot if you get me pointed in the right direction.
downloads and looks at code
I see that tzcode2002c.tar.gz includes a mktime() function. Is the idea
to pull this out (with just
I've altered the PL/Tcl build to use the configured compiler, not the one
Tcl wants, pursuant to earlier discussion. This leaves open the issue of
the export file that libpgtcl needs on AIX. That looked too confusing to
me to touch it.
--
Peter Eisentraut [EMAIL PROTECTED]
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 24, 2002 1:33 PM
To: Joel Burton
Cc: Pgsql-Hackers@Postgresql. Org
Subject: Re: [HACKERS] Exposed function to find table in schema search
list?
At the moment regclass conversion raises an error if the
Michael Meskes writes:
Or does the -34 mean more than just the RedHat version number? The
Debian version is correctly named 2.2.5-6 where the -6 means that this
is the 6th release of glibc 2.2.5 for Debian,
Just for general amusement: I run SuSE's glibc 2.2.5-38 which contains
neither the
Per previous discussion, I have committed changes that cause the btree
and hash index methods to mark index tuples killed the first time they
are fetched after becoming globally dead. Subsequently the killed
entries are not returned out of indexscans, saving useless heap fetches.
(I haven't
This is the first time I have ever seen repeated pgbench runs without
substantial performance degradation. Not a bad result for a Friday
afternoon...
Congatulations :-) This sounds great !!!
Andreas
---(end of broadcast)---
TIP 5: Have you
Joel Burton [EMAIL PROTECTED] writes:
At the moment regclass conversion raises an error if the item isn't
found; this follows the historical behavior of regproc. We could
possibly have it return 0 (InvalidOid) instead, but I'm not convinced
that that's better. In the case of regproc, not
Tom Lane wrote:
The remaining degradation is actually in seqscan performance, not
indexscan --- unless one uses a much larger -s setting, the planner will
think it ought to use seqscans for updating the branches and tellers
tables, since those nominally have just a few rows; and there's no
On Sat, 2002-05-25 at 02:38, Joe Conway wrote:
Tom Lane wrote:
The remaining degradation is actually in seqscan performance, not
indexscan --- unless one uses a much larger -s setting, the planner will
think it ought to use seqscans for updating the branches and tellers
tables, since
Joe Conway [EMAIL PROTECTED] writes:
This may qualify as a way out there idea, or more trouble than it's
worth, but what about a table option which provides a bitmap index of
tuple status -- i.e. tuple dead t/f. If available, a seqscan in between
vacuums could maybe gain some of the same
Tom Lane wrote:
Well, that's the zeroth-order approximation. We should take the
opportunity to get out from under the mktime()/tzset() API. The real
idea here is to make use of the timezone database info in the ways that
Postgres needs. Some things that are not good about mktime()/tzset():
...
Well, this does sound a bit more involved than I was envisioning. There
are a few items wrt SRFs that I should finish first, but I'll come back
to this afterward if no one else does first.
The first cut might be to reproduce the functionality we already have.
That would allow us to
Thomas Lockhart [EMAIL PROTECTED] writes:
The last phase could be extending the API to allow multiple simultaneous
time zones, detection of bad time zones, etc etc. This would involve API
changes or extensions, and breaks compatibility with system-supplied
infrastructure.
One thing that
The last phase could be extending the API to allow multiple simultaneous
time zones, detection of bad time zones, etc etc. This would involve API
changes or extensions, and breaks compatibility with system-supplied
infrastructure.
One thing that wasn't clear to me, but could use
Thomas Lockhart [EMAIL PROTECTED] writes:
The fundamental problem (which of course can have a fundamental solution
;) is that a time zone database built with a 32-bit time_t will have
time zone info through 2038 only (it is a binary file with 32-bit time
fields -- almost certainly anyway).
The last phase could be extending the API to allow multiple simultaneous
time zones, detection of bad time zones, etc etc. This would involve API
changes or extensions, and breaks compatibility with system-supplied
infrastructure.
One thing that wasn't clear to me, but could use
On Fri, 24 May 2002, Peter Eisentraut wrote:
Michael Meskes writes:
Or does the -34 mean more than just the RedHat version number? The
Debian version is correctly named 2.2.5-6 where the -6 means that this
is the 6th release of glibc 2.2.5 for Debian,
Just for general amusement: I
27 matches
Mail list logo
