At 10:51 23/05/02 -0400, Tom Lane wrote:
>"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > So who was it that wanted to make this change. Perhaps I can help.
>
>I forget who had volunteered to work on it, but it was several months
>ago and nothing's happened ...
Not sure if this is the right r
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 amusem
> > > 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
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
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
...
> 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 (opt
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
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
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"
> > table
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'
"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 regp
> 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
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 cha
> -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
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
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]
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.
>
> I see that tzcode2002c.tar.gz includes a mktime() function. Is the idea
> to pull this out (with just whatever support it needs
"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 chang
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
> ;-) ... w
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.
Table
> -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]> w
[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 sev
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 PROT
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 us
...
> 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 o
26 matches
Mail list logo
