Tom Lane <[EMAIL PROTECTED]> writes:
> "Mario Weilguni" <[EMAIL PROTECTED]> writes:
> > Why is floor not working anymore?
>
> Mph. Seems we have floor(numeric) but not floor(float8), and the latter
> is what you need here.
Sorry, I missed much of the casting discussion -- but is there a
reason
On Thu, Oct 03, 2002 at 10:26:16PM +1000, Justin Clift wrote:
> Have been thinking for a while now about viable ways to Open Source the
> Flash based training material that has been in development from last
> year.
>
> After discussing this with a number of people for suggestions, feedback,
> ad
I wrote:
> > The REAL issue and the one that will greatly affect total system
> > throughput is that of contention on the file locks. Since
> fsynch needs to
> > obtain a write lock on the file descriptor, as does the write
> calls which
> > originate from XLogWrite as the writes are written to th
Bruce Momjian wrote:
> I may be missing something here, but other backends don't block while
> one writes to WAL.
I don't think they'll block until they get to the fsync or XLogWrite
call while another transaction is fsync'ing.
I'm no Unix filesystem expert but I don't see how the OS can
handle
I wrote:
> > My modification was to use access counts to increase the
> durability of the
> > more accessed blocks.
>
tom lane replies:
> You could do it that way too, but I'm unsure whether the extra
> complexity will buy anything. Ultimately, I think an LRU-anything
> algorithm is equivalent
Oliver Elphick <[EMAIL PROTECTED]> writes:
> I can see that the current behaviour might give surprising results in a
> long running transaction. Surprise could be reduced by giving the time
> of first use within the transaction rather than the start of the
> transaction.
[ cogitates ... ] Hmm,
On Fri, 2002-10-04 at 01:41, Bruce Momjian wrote:
> Well, let's see what others say. If no one is excited about the change,
> we can just document its current behavior. Oh, I see it is already
> documented in func.sgml:
>
> It is quite important to realize that
> CURRENT_TIMESTAMP and r
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused how yours differs from mine. I don't see how the last
> matching tagged query would not be from an INSTEAD rule.
You could have both INSTEAD and non-INSTEAD rules firing for the same
original query. If the alphabetically-last rule is a n
"Curtis Faith" <[EMAIL PROTECTED]> writes:
> The REAL issue and the one that will greatly affect total system
> throughput is that of contention on the file locks. Since fsynch needs to
> obtain a write lock on the file descriptor, as does the write calls which
> originate from XLogWrite as the wr
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We have talked about possible return values for RULES, particularly
> > INSTEAD rule. Manfred has a nice example here, so I propose we handle
> > INSTEAD rules this way: that we return the oid and tuple count of the
> > last INSTEAD
Curtis Faith wrote:
> The method I propose does not result in any blocking because of writes
> other than the final commit's write and it has the very significant
> advantage of allowing other transactions (from other back-ends) to
> continue until they enter commit (and blocking waiting for their
tom lane replies:
> "Curtis Faith" <[EMAIL PROTECTED]> writes:
> > So, why don't we use files opened with O_DSYNC | O_APPEND for
> the WAL log
> > and then use aio_write for all log writes?
>
> We already offer an O_DSYNC option. It's not obvious to me what
> aio_write brings to the table (asi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We have talked about possible return values for RULES, particularly
> INSTEAD rule. Manfred has a nice example here, so I propose we handle
> INSTEAD rules this way: that we return the oid and tuple count of the
> last INSTEAD rule query with a tag mat
At 11:07 PM 3/10/2002 -0400, Tom Lane wrote:
>A non-integral representation
>of off_t is theoretically possible but I don't believe it exists in
>practice.
Excellent. So I can just read/write the bytes in an appropriate order and
expect whatever size it is to be a single intXX.
Fine with me, un
Tom Lane wrote:
> Giles Lean <[EMAIL PROTECTED]> writes:
> > When talking of near-current systems with 64 bit off_t you are not
> > going to find one without support for 64 bit integral types.
>
> I tend to agree with Giles on this point. A non-integral representation
> of off_t is theoretically
Giles Lean <[EMAIL PROTECTED]> writes:
> When talking of near-current systems with 64 bit off_t you are not
> going to find one without support for 64 bit integral types.
I tend to agree with Giles on this point. A non-integral representation
of off_t is theoretically possible but I don't believ
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Have people considered flock (advisory locking) on the postmaster.pid
> file for backend detection?
$ man flock
No manual entry for flock.
$
HPUX has generally taken the position of adopting both BSD and SysV
features, so if it doesn't exist here, it's
Added to TODO:
* Add floor(float8) and other missing functions
---
Tom Lane wrote:
> "Mario Weilguni" <[EMAIL PROTECTED]> writes:
> > I noticed that some of my queries don't work anymore because they're using
> > t
Jim, glad you are still around. Yes, we would love to get tablespaces
in 7.4. I think we need to think bigger and get something where we can
name tablespaces and place tables/indexes into these named spaces. I
can reread the TODO.detail stuff and give you an outline. How does that
sound? Tho
We have talked about possible return values for RULES, particularly
INSTEAD rule. Manfred has a nice example here, so I propose we handle
INSTEAD rules this way: that we return the oid and tuple count of the
last INSTEAD rule query with a tag matching the main query. The
returned tag, of cours
Thomas Lockhart wrote:
> ...
> > Seems that isn't helping enough to reduce the number of people who are
> > surprised by our behavior. I don't think anyone would be surprised by
> > statement time.
>
> I think that there is no compelling reason for changing the current
> behavior. There is no *
Just a reminder, we are not using this tag. All 7.3 patches are going
to HEAD. Once we decide to split the tree for 7.4, we will update this
branch and announce it is ready to be used.
---
Marc G. Fournier wrote:
>
> As
Have people considered flock (advisory locking) on the postmaster.pid
file for backend detection? It has a nonblocking option. Don't most
OS's support it?
I can't understand why we can't get an easier solution to postmaster
detection than shared memory.
--
Philip Warner writes:
> Yes, but there is no guarantee that off_t is implemented as such, nor would
> we be wise to assume so (most docs say explicitly not to do so).
I suspect you're reading old documents, which is why I asked what you
were referring to. In the '80s what you are saying would
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > So, in summary, reasons for the change:
> > more intuitive
> > more standard-compliant
> > more closely matches other db's
>
> I'd give you the first and third of those. As Andrew noted, the
> argument that "it's more st
Greg Copeland wrote:
-- Start of PGP signed section.
> Hey, excellent. Thanks!
>
> Based on that, it appears that XFS is a pretty good FS to use. For me,
> the real surprise was how well reiserfs performed.
>
OK, hardware performance paper updated:
---
On Thu, Oct 03, 2002 at 07:09:33PM -0400, Tom Lane wrote:
> statement-arrival time. (I like the idea of a parameterized version of
> now() to provide a consistent interface to all three functionalities.)
I like this, too. I think it'd be probably useful. But. . .
> pride of place to statemen
John Worsley <[EMAIL PROTECTED]> writes:
> I just stumbled across this peculiarity in PL/Perl today writing a method
> to invoke Perl Regexes from a function: if a run-time error is raised in
> an otherwise good function, the function will never run correctly again
> until the connection to the da
At 07:15 AM 4/10/2002 +1000, Giles Lean wrote:
> > My limited reading of off_t stuff now suggests that it would be brave to
> > assume it is even a simple 64 bit number (or even 3 32 bit numbers).
>
>What are you reading?? If you find a platform with 64 bit file
>offsets that doesn't support 64
Hey, excellent. Thanks!
Based on that, it appears that XFS is a pretty good FS to use. For me,
the real surprise was how well reiserfs performed.
Greg
On Thu, 2002-10-03 at 18:09, Mike Benoit wrote:
> Some of you may be interested in this seemingly exhaustive benchmark
> between ext2/3, Reise
"Curtis Faith" <[EMAIL PROTECTED]> writes:
> So, why don't we use files opened with O_DSYNC | O_APPEND for the WAL log
> and then use aio_write for all log writes?
We already offer an O_DSYNC option. It's not obvious to me what
aio_write brings to the table (aside from loss of portability).
You
Some of you may be interested in this seemingly exhaustive benchmark
between ext2/3, ReiserFS, JFS, and XFS.
http://www.osdl.org/presentations/lwe-jgfs.pdf
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.post
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So, in summary, reasons for the change:
> more intuitive
> more standard-compliant
> more closely matches other db's
I'd give you the first and third of those. As Andrew noted, the
argument that "it's more standard-compliant" is not v
"Curtis Faith" <[EMAIL PROTECTED]> writes:
> Then during execution if the planner turned out to be VERY wrong about
> certain assumptions the execution system could update the stats that led to
> those wrong assumptions. That way the system would seek the correct values
> automatically.
That has
I've been looking at the TODO lists and caching issues and think there may
be a way to greatly improve the performance of the WAL.
I've made the following assumptions based on my reading in the manual and
the WAL archives since about November 2000:
1) WAL is currently fsync'd before commit succe
tom lane wrote:
> But more globally, I think that our worst problems these days have to do
> with planner misestimations leading to bad plans. The planner is
> usually *capable* of generating a good plan, but all too often it picks
> the wrong one. We need work on improving the cost modeling equ
Andrew Sullivan wrote:
> On Thu, Oct 03, 2002 at 04:18:08PM -0400, Bruce Momjian wrote:
> >
> > So, we have a couple of decisions to make:
> >
> > Should CURRENT_TIMESTAMP be changed to "statement arrival time"?
> > Should now() be changed the same way?
> > If not, should now() and C
On Thu, Oct 03, 2002 at 04:18:08PM -0400, Bruce Momjian wrote:
>
> So, we have a couple of decisions to make:
>
> Should CURRENT_TIMESTAMP be changed to "statement arrival time"?
> Should now() be changed the same way?
> If not, should now() and CURRENT_TIMESTAMP return the sam
Good day,
I just stumbled across this peculiarity in PL/Perl today writing a method
to invoke Perl Regexes from a function: if a run-time error is raised in
an otherwise good function, the function will never run correctly again
until the connection to the database is reset. I poked around in the
On Thu, Oct 03, 2002 at 04:00:32PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where are we with this patch?
>
> It's done as far as I'm concerned ;-). Not sure if Hannu still wants
> to argue that the behavior is wrong ... it seems fine to me though ...
I still haven
Philip Warner writes:
> My limited reading of off_t stuff now suggests that it would be brave to
> assume it is even a simple 64 bit number (or even 3 32 bit numbers).
What are you reading?? If you find a platform with 64 bit file
offsets that doesn't support 64 bit integral types I will not
Bruce Momjian wrote:
> I am getting errors when doing a checkout, related to Marc's splitting
> up the CVS tree into modules:
>
> C pgsql/contrib/earthdistance/Makefile
> cvs checkout: move away
> pgsql/contrib/earthdistance/README.earthdistance; it is in the way
> C
On Fri, 2002-10-04 at 01:00, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where are we with this patch?
>
> It's done as far as I'm concerned ;-). Not sure if Hannu still wants
> to argue that the behavior is wrong ... it seems fine to me though ...
I stop arguing for now, "O
[ Thread moved to hackers.]
OK, I have enough information from the various other databases to make a
proposal. It seems the other databases, particularly Oracle, record
CURRENT_TIMESTAMP as the time of statement start. However, it isn't the
time of statement start from the user's perspective,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Where are we with this patch?
It's done as far as I'm concerned ;-). Not sure if Hannu still wants
to argue that the behavior is wrong ... it seems fine to me though ...
regards, tom lane
---(end of bro
Tino Wildenhain <[EMAIL PROTECTED]> wrote:
> Hi Justin,
>
> > Good point. For the moment we've whipped up that MS Excel document
> > (created in OpenOffice of course) of all the English text strings in the
> > site and emailed it to the volunteers. :)
>
> Btw. did you ever unzip the native Open
Where are we with this patch?
---
Alvaro Herrera wrote:
> On 29 Sep 2002, Hannu Krosing wrote:
>
> > On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
> > > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > > I'd propose that ADD
On Thursday 03 October 2002 02:31 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> One thing that confuses me though is that the build options have been
> like this for a long time (at least since 7.1). Why haven't you seen
> this problem before? Did you recently change the way the
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Interesting. The inconsistency you're seeing is a result of GEQO. I
> > would have hoped that it would have produced a better quality plan
> > more often, but apparently not. On my system, the regular query
> > optimizer handily beats G
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Zeugswetter Andreas SB SD wrote:
>
> > > > >
Adrian 'Dagurashibanipal' von Bidder wrote:
-- Start of PGP signed section.
> On Wed, 2002-10-02 at 16:14, Marc G. Fournier wrote:
> >
> > Just in case anyone enjoys these sorts of things :) It deals with the
> > whole .org TLD assignment ...
> >
> > http://forum.icann.org/org-eval/gartner-
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Never mind! I just stumbled over those lines in selfuncs.c where
> indexCorrelation is calculated by dividing the correlation of the
> first index column by the number of index columns.
Yeah, I concluded later that that was bogus. I've been thinking
Lamar Owen <[EMAIL PROTECTED]> writes:
> So the regression tests weren't really testing the actually built module, so
> to speak. Is there a good reason to leave the NOTICE's in the expected
> regression output?
Yes: without them the test is less useful, because you're less certain
that what h
On Wed, 2002-10-02 at 16:14, Marc G. Fournier wrote:
>
> Just in case anyone enjoys these sorts of things :) It deals with the
> whole .org TLD assignment ...
>
> http://forum.icann.org/org-eval/gartner-report
I like this one:
| Unlike many of the conventional commercial databases, Post
On Thursday 03 October 2002 12:29 am, Lamar Owen wrote:
> RPMs will be uploaded either tonight or tomorrow morning after I get to
> work; it will depend on how much upload bandwidth I can get out of this
> dialup. It appears to be running OK, so I may let it run.
RPMS uploaded into the usual
On Thursday 03 October 2002 12:46 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Builds fine here for RPM usage. Got an odd diff in the triggers
> > regression test: did we drop a NOTICE? If so, the regression output
> > should probably have been changed too. The diff:
> > ***
On Thu, 3 Oct 2002 10:59:54 -0600 (MDT), "scott.marlowe"
<[EMAIL PROTECTED]> wrote:
>>are multicolunm indices involved in your estimator problems?
>
>No. Although I use them a fair bit, none of the problems I've encountered
>so far have involved them. But I'd be willing to setup some test index
Tino Wildenhain wrote:
> Haha cut&paste ;-) Ever heard of csv? :-))
>
> However, I can also have a look at it, if desired.
Heh Heh Heh
Good point. For the moment we've whipped up that MS Excel document
(created in OpenOffice of course) of all the English text strings in the
site and emailed
I have added this to backend/libpq/README.SSL to be integrated into our
main docs later.
---
Bear Giles wrote:
> A second cut at SSL documentation
>
>
>
> SSL Support in PostgreSQL
> =
>
> Wh
Samuel A Horwitz wrote:
> has this patched been applied to the CVS yet?
No, I was waiting to see if there were any negative comments, but seeing
none, I will add it to the patch queue today.
---
>
>
> On Tue, 1 Oct 2002,
Patch applied. Thanks.
---
Mario Weilguni wrote:
> This small patch adds a Makefile for /contrib/reindexdb/ and renames the README to
>README.reindexdb.
>
> Regards,
> Mario Weilguni
[ Attachment, skipping... ]
Patch applied. Thanks.
---
Mario Weilguni wrote:
> It's just a cosmetic change, fixes the help screen. Should be applied in
>/contrib/vacuumlo
>
> Regards,
> Mario Weilguni
[ Attachment, skipping... ]
>
> -
Patch applied. Thanks.
---
Mario Weilguni wrote:
> It's just a cosmetic change, fixes the help screen. Should be applied in
>/contrib/vacuumlo
>
> Regards,
> Mario Weilguni
[ Attachment, skipping... ]
>
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> This will work nicely for the regression tests' purposes. If there is
> >> anyone out there actually using refint.c in production, they might be
> >> annoyed by the NOTICE chatter, but quite honestly I doubt anyo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This will work nicely for the regression tests' purposes. If there is
>> anyone out there actually using refint.c in production, they might be
>> annoyed by the NOTICE chatter, but quite honestly I doubt anyone is ---
>> this contrib
Patch applied. Thanks.
---
Teodor Sigaev wrote:
> This is small README fix for contrib/intarray. Thank you.
> --
> Teodor Sigaev
> [EMAIL PROTECTED]
>
[ application/gzip is not supported, skipping... ]
>
> -
Patch applied. Thanks.
---
Joe Conway wrote:
> Tom Lane wrote:
> > It might work to measure time since the start of the whole process, or
> > until the timeout target, rather than accumulating adjustments to the
> > "rema
Patch applied. Thanks.
---
Joe Conway wrote:
> Masaru Sugawara wrote:
> > The previous patch fixed an infinite recursion bug in
> > contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> > seems to occu
Tom Lane wrote:
> I said:
> > I am inclined to have the refint.c code emit the notice unconditionally
> > at DEBUG1 level, and then add a "SET client_min_messages = DEBUG1" in
> > the triggers regression test to ensure the notice will appear.
>
> Hmm, that doesn't look that good after all: the SE
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> I had a brain wave and did the cvs log command which was what lead me to try
> specifying revisions. As I say it looks like a lack of knowledge about how cvs
> works for these things. I always thought it worked like RCS and gave a diff
> against the
On Thu, 3 Oct 2002, Manfred Koizar wrote:
> On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), "scott.marlowe"
> <[EMAIL PROTECTED]> wrote:
> >I've found that when the planner misses, sometimes it misses
> >by HUGE amounts on large tables,
>
> Scott,
>
> yet another question: are multicolunm indices inv
Hi Tino,
Tino Wildenhain wrote:
>
> Hi Justin,
>
> you want probably use the language-negotiation
> rather then a query variable :-)
Um, language-negotiation in good in theory, but there are real world
scenarios it doesn't take into account. :(
However, the query variable is an override, and
I said:
> I am inclined to have the refint.c code emit the notice unconditionally
> at DEBUG1 level, and then add a "SET client_min_messages = DEBUG1" in
> the triggers regression test to ensure the notice will appear.
Hmm, that doesn't look that good after all: the SET causes the
regression outp
On Thu, 3 Oct 2002, Manfred Koizar wrote:
> On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), "scott.marlowe"
> <[EMAIL PROTECTED]> wrote:
> >I'd certainly be willing to do some testing on my own data with them.
>
> Great!
>
> >Gotta patch?
>
> Not yet.
>
> > I've found that when the planner misses
On Thu, 03 Oct 2002 21:47:03 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
>I believe that was vacuum analyze only.
Well there is
VACUUM [tablename];
and there is
ANALYZE [tablename];
And
VACUUM ANALYZE [tablename];
is VACUUM followed by ANALYZE.
Servus
Lamar Owen <[EMAIL PROTECTED]> writes:
> Builds fine here for RPM usage. Got an odd diff in the triggers regression
> test: did we drop a NOTICE? If so, the regression output should probably
> have been changed too. The diff:
> *** ./expected/triggers.out Sat Jan 15 14:18:23 2000
> --- ./
On 3 Oct 2002 at 11:57, Robert Treat wrote:
> NOTE: Setting follow up to the performance list
>
> Funny that the status quo seems to be if you need fast selects on data
> that has few inserts to pick mysql, otherwise if you have a lot of
> inserts and don't need super fast selects go with Postgre
On Thu, 03 Oct 2002 18:06:10 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
>Machine
>Compaq Proliant Server ML 530
>
>"Intel Xeon 2.4 Ghz Processor x 4, "
Nigel J. Andrews wrote:
> It gave me the log all the way up to the 1.64 revision with the REL7_3_STABLE
> label assigned to revision 1.64.0.2
>
> Revision 1.64 apparently backing out my patch which made 1.63.
>
> I had a brain wave and did the cvs log command which was what lead me to try
> spec
On 3 Oct 2002 at 11:23, Greg Copeland wrote:
> On Thu, 2002-10-03 at 10:56, Shridhar Daithankar wrote:
> > Well, we were comparing ext3 v/s reiserfs. I don't remember the journalling
> > mode of ext3 but we did a 10 GB write test. Besides converting the RAID to RAID-
> > 0 from RAID-5 might have
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), "scott.marlowe"
<[EMAIL PROTECTED]> wrote:
>I've found that when the planner misses, sometimes it misses
>by HUGE amounts on large tables,
Scott,
yet another question: are multicolunm indices involved in your
estimator problems?
Servus
Manfred
---
On Thu, 2002-10-03 at 10:56, Shridhar Daithankar wrote:
> Well, we were comparing ext3 v/s reiserfs. I don't remember the journalling
> mode of ext3 but we did a 10 GB write test. Besides converting the RAID to RAID-
> 0 from RAID-5 might have something to do about it.
>
> There was a discussion
On Thu, 3 Oct 2002, Bruce Momjian wrote:
> Nigel J. Andrews wrote:
> > cvs diff -r HEAD pltcl.c
> >
> > gave me differences against revision 1.64
> >
> > and cvs update pltcl.c
> >
> > said it was merging changes between 1.64 and 1.61
> >
> > and a plain cvs diff now shows me differences agai
Shridhar Daithankar wrote:
> > Was the original posting on GENERAL or HACKERS. Is this moving the
> > PERFORMANCE for follow-up? I'd like to follow this discussion and want
> > to know if I should join another group?
>
> Shall I subscribe to performance? What's the exat list name? Benchmarks?
On 3 Oct 2002 at 8:54, Charles H. Woloszynski wrote:
> Can you comment on the tools you are using to do the insertions (Perl,
> Java?) and the distribution of data (all random, all static), and the
> transaction scope (all inserts in one transaction, each insert as a
> single transaction, some
has this patched been applied to the CVS yet?
On Tue, 1 Oct 2002, Zeugswetter
Andreas SB SD wrote:
> Date: Tue, 1 Oct 2002 10:23:13 +0200
> From: Zeugswetter Andreas SB SD <[EMAIL PROTECTED]>
> To: Peter Eisentraut <[EMAIL PROTECTED]>
> Cc: PostgreSQL Development <[EMAIL PROTECTED]>
> Subject:
Nigel J. Andrews wrote:
> cvs diff -r HEAD pltcl.c
>
> gave me differences against revision 1.64
>
> and cvs update pltcl.c
>
> said it was merging changes between 1.64 and 1.61
>
> and a plain cvs diff now shows me differences against 1.64
>
> I think this is probably just a short fall in my
On Thu, 3 Oct 2002, Bruce Momjian wrote:
> Nigel J. Andrews wrote:
> >
> >
> > I've been waiting to see how a patched file differs from my version.
> >
> > The patch was added to the to apply list last week I think (it wasn't mine btw)
> > and I've been doing cvs diff to view the differences s
NOTE: Setting follow up to the performance list
Funny that the status quo seems to be if you need fast selects on data
that has few inserts to pick mysql, otherwise if you have a lot of
inserts and don't need super fast selects go with PostgreSQL; yet your
data seems to cut directly against this.
> Um, doesn't "world's" mean "world is" ?
i forgot to provide a real-world example:
http://www.amazon.com/
"Earth's Biggest Selection"
-tfo
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-
"Thomas F.O'Connell" wrote:
>
> > Um, doesn't "world's" mean "world is" ?
>
> In this situation, the "'s" denotes possession, as in "the most advanced
> open source database of the world".
>
> "worlds" here is basically saying "every world most advanced open source
> database" and does not, in
On 3 Oct 2002 at 19:33, Shridhar Daithankar wrote:
> On 3 Oct 2002 at 13:56, Nigel J. Andrews wrote:
> > It's one hell of a DB you're building. I'm sure I'm not the only one interested
> > so to satisfy those of us who are nosey: can you say what the application is?
> >
> > I'm sure we'll all un
On Thu, 03 Oct 2002 12:40:20 +0200, I wrote:
>>Gotta patch?
>
>Yes, see below.
Oh, did I mention that inserting some break statements after the
switch cases helps a lot? :-(
Cavus venter non laborat libenter ...
Servus
Manfred
---(end of broadcast)-
> Um, doesn't "world's" mean "world is" ?
In this situation, the "'s" denotes possession, as in "the most advanced
open source database of the world".
"worlds" here is basically saying "every world most advanced open source
database" and does not, in any case, connote possession.
-tfo
-
Thomas O'Connell wrote:
>
> > Is anyone interested in translating the English version to other
> > languages?
>
> I don't have time for the translation, unfortunately, but i would
> suggest changing "worlds" to "world's" on the main page.
Um, doesn't "world's" mean "world is" ?
That wouldn't m
Nigel J. Andrews wrote:
>
>
> I've been waiting to see how a patched file differs from my version.
>
> The patch was added to the to apply list last week I think (it wasn't mine btw)
> and I've been doing cvs diff to view the differences so I can tell when the
> patch has been applied. Addition
> Is anyone interested in translating the English version to other
> languages?
I don't have time for the translation, unfortunately, but i would
suggest changing "worlds" to "world's" on the main page.
-tfo
---(end of broadcast)---
TIP 1: subscr
Lamar Owen <[EMAIL PROTECTED]> writes:
> Builds fine here for RPM usage. Got an odd diff in the triggers regression
> test: did we drop a NOTICE? If so, the regression output should probably
> have been changed too.
No, we didn't change anything, and the 7.2 regression tests passed for
me on
>My limited reading of off_t stuff now suggests that it would be brave to
>assume it is even a simple 64 bit number (or even 3 32 bit numbers). One
>alternative, which I am not terribly fond of, is to have pg_dump write
>multiple files - when we get to 1 or 2GB, we just open another file, and
At 11:06 AM 2/10/2002 -0400, Tom Lane wrote:
>It needs to get done; AFAIK no one has stepped up to do it. Do you want
>to?
My limited reading of off_t stuff now suggests that it would be brave to
assume it is even a simple 64 bit number (or even 3 32 bit numbers). One
alternative, which I am n
1 - 100 of 108 matches
Mail list logo
