contrib/ltree, contrib/tsearch, and contrib/tsearch2 each contain
implementations of CRC32 calculations. I think these are now pretty
redundant with the CRC32 code existing in the main backend. They
use a different CRC polynomial than the main backend code does,
but it's hard to credit that that
Alon Goldshuv wrote:
> I think that the basic issue is that there are some database users that would
> like to take their data and put it into the database without pre-processing
> it [...]
> The only responsibility of these users is to explicitly escape any delimiter
> or 0x0A (LF) characters
contrib/ltree, contrib/tsearch, and contrib/tsearch2 each contain
implementations of CRC32 calculations. I think these are now pretty
redundant with the CRC32 code existing in the main backend. They
use a different CRC polynomial than the main backend code does,
but it's hard to credit that that
On Thu, Jun 02, 2005 at 12:30:01AM -0400, Alon Goldshuv wrote:
> before that, let me just clarify that the performance improvements in
> the patch have nothing to do with the escaping mechanizm. Escapes
> could change. The performance gain in due to a buffered processing
> with minimal line/attrib
Steve,
Oops. Example below should have read differently:
> Sample with 2 identical rows (with binary representations depicted between
> <>):
> Blahblah<0xaa>blahblah<0x09>blahblah<0x00>blahblah<0xaa>Blahblah<0xaa>blahbl
> ah<0x09>blahblah<0x00>blahblah<0xaa>
Blahblah<0x0a>blahblah<0x09>blahbla
>I've been following this thread, and I'm a little confused. Could you
possibly clarify what you mean, by providing a couple of lines of
input as it would be formatted with escape processing turned off -
containing a text field with an embedded newline and tab and a null field.
yeah, this is all
yeah, this is all a bit confusing, but I *hope* I can clarify things here as I
think I got a better understanding now.
before that, let me just clarify that the performance improvements in the patch
have nothing to do with the escaping mechanizm. Escapes could change. The
performance gain in du
Steve,
> I've been following this thread, and I'm a little confused. Could you
> possibly clarify what you mean, by providing a couple of lines of
> input as it would be formatted with escape processing turned off -
> containing a text field with an embedded newline and tab and a null field.
Usin
Here is a summary of the issues with moving to no escapes for non-E
strings:
http://candle.pha.pa.us/cgi-bin/pgescape
---
Bruno Wolff III wrote:
> On Tue, May 31, 2005 at 11:49:20 +0200,
> Dennis Bjorklund <[EMAIL
On Wed, Jun 01, 2005 at 10:35:30AM -0700, Alon Goldshuv wrote:
> 2) A modified command syntax for introducing a direct single row error
> handling. By direct I mean - a row that if rejected from within the COPY
> command context does not throw an error and rollsback the whole transaction.
> Instea
Is there any reason we can't have SELECT FOR UPDATE on union ALL queries?
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Wed, Jun 01, 2005 at 07:35:33PM -0700, Luke Lonergan wrote:
> >> I propose an extended syntax to COPY with a change in semantics to remove
> >> the default of "WITH ESCAPE '\'".
> >
> > Er, doesn't this break existing database dumps?
>
> Yes, one of the previously stated reasons to create anot
> How do you distinguis an escape-delimiter used to escape a delimiter in
> the data from a literal escape-delimiter in the data being loaded --- it
> seems impossible to do.
The usual approach is fine - a pair of escapes is equivalent to a literal
escape.
> Or are you saying there would be no
Oliver,
On 6/1/05 7:13 PM, "Oliver Jowett" <[EMAIL PROTECTED]> wrote:
> Luke Lonergan wrote:
>
>> I propose an extended syntax to COPY with a change in semantics to remove
>> the default of "WITH ESCAPE '\'".
>
> Er, doesn't this break existing database dumps?
Yes, one of the previously stated
Oliver Jowett wrote:
> Luke Lonergan wrote:
>
> > I propose an extended syntax to COPY with a change in semantics to remove
> > the default of "WITH ESCAPE '\'".
>
> Er, doesn't this break existing database dumps?
Right, we will not change the default.
--
Bruce Momjian
Luke Lonergan wrote:
>
> >
> > Yep, we would _love_ those improvements.
> >
>
> Coming soon, probably from the guy you've never heard of :-)
LOL
> >
> > I am confused why you are confused. :-)
> >
> > Uh, how do you do the escapes if you don't double the escape character
> > on input so yo
Luke Lonergan wrote:
I propose an extended syntax to COPY with a change in semantics to remove
the default of "WITH ESCAPE '\'".
Er, doesn't this break existing database dumps?
-O
---(end of broadcast)---
TIP 3: if posting/reading through Usene
""Magnus Hagander"" <[EMAIL PROTECTED]>
> > Why not just use the pid in teh name, and have one segment
> > per backend?
> >
> > Being used only for signals you mean? That might work.
>
> That was my idea. We'll end up using three global namespace objects
> (mutex+event+shared memory) instead of
>
> Yep, we would _love_ those improvements.
>
Coming soon, probably from the guy you've never heard of :-)
>
> I am confused why you are confused. :-)
>
> Uh, how do you do the escapes if you don't double the escape character
> on input so you can distinguish a literal escape from one use
Bruce,
> Yep, you have to double backslahses coming in as data so we can use
> backslash for marking null, delimiters, etc. I see no way around that,
> and no one since Berkeley has come up with one either. If you have an
> idea, we would _love_ to hear it.
Apropos to the previous thread on esc
Patch applied. Thanks for the COPY \x patch.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Here is a new version of the three \x hex support patches. I have added
> > > \x for psql variables,
Luke Lonergan wrote:
> Tom,
> >
> > ... and instead, define some new behavior that will soon be considered
> > broken legacy code itself?
>
> I'll not argue further about whether to have a separate LOAD command.
> That's not as important as fixing the performance issues in the data load
> path in
Alon Goldshuv wrote:
> Bruce,
>
> The patch is not there to show that something is "broken" is it there to
> show how things could be done in another way, which may or may not be more
> desireable.
Sure, we are always looking for ways to improve things.
> > COPY works as designed. The idea that
Tom,
>
> ... and instead, define some new behavior that will soon be considered
> broken legacy code itself?
I'll not argue further about whether to have a separate LOAD command.
That's not as important as fixing the performance issues in the data load
path in PostgreSQL to me.
However, I find i
Bruce,
The patch is not there to show that something is "broken" is it there to
show how things could be done in another way, which may or may not be more
desireable.
> COPY works as designed. The idea that some guy we have never heard of
> is going to appear and rewrite COPY's processing and te
Simon Riggs wrote:
On Wed, 2005-06-01 at 10:35 -0700, Alon Goldshuv wrote:
2) A modified command syntax for introducing a direct single row error
handling. By direct I mean - a row that if rejected from within the COPY
5) allow an ERRORLIMIT to allow control of aborting a load after a certain
Simon Riggs wrote:
> I'm not clear from all of those options whether we still need a LOAD
> command, based upon other issues/comments raised on this thread.
>
> However, there are some other arguments for why it might be a good idea
> to have a LOAD DATA command separate from COPY. Certainly long
Tom Lane wrote:
> Bruce Momjian writes:
> > One idea would be to look at the table file size first. If it has zero
> > blocks, lock the table and if it still has zero blocks, do the no-WAL
> > copy.
>
> I think that's a bad idea. It would make the behavior unpredictable
> --- sometimes a COPY w
Luke Lonergan wrote:
> Bruce,
>
> > The problem with a new command is that it becomes unclear when you
> > should use COPY and when LOAD DATA, and it confuses users, and has
> > maintenance overhead. If Bizgres wants a new command name, go for it,
> > but it is unlikely that the community release
On Wed, 2005-06-01 at 18:32 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > One idea would be to look at the table file size first. If it has zero
> > blocks, lock the table and if it still has zero blocks, do the no-WAL
> > copy.
>
> I think that's a bad idea. It would make the behavior unp
On Wed, 2005-06-01 at 10:35 -0700, Alon Goldshuv wrote:
> I have been working on improving the COPY command performance
> Around 40% for 15 column (mixed types) table.
> Around 90% for 1 column table.
Thats very cool.
> 2) A modified command syntax for introducing a direct single row error
> h
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> One of the reasons to consider a LOAD DATA command is that we can isolate
> the need for performance improvements and special syntax from the concerns
> of preserving the legacy behavior of COPY for use as the primary mechanism
> for DUMP and RESTORE.
Bruce Momjian writes:
> One idea would be to look at the table file size first. If it has zero
> blocks, lock the table and if it still has zero blocks, do the no-WAL
> copy.
I think that's a bad idea. It would make the behavior unpredictable
--- sometimes a COPY will take an exclusive lock, an
Bruce,
> The problem with a new command is that it becomes unclear when you
> should use COPY and when LOAD DATA, and it confuses users, and has
> maintenance overhead. If Bizgres wants a new command name, go for it,
> but it is unlikely that the community release is going to go in that
> directi
Simon Riggs wrote:
> Is it possible that you could put sufficient of the application into
> PostgreSQL to genericise some features? Stonebraker's Third Wave was
> *all* about putting data intensive operations closer to where the data
> is stored/accessed.
And just like that, a lightbulb goes off i
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Not unless you are proposing to change COPY to acquire a lock strong
> >> enough to lock out other writers to the table for the duration ...
>
> > Well, if the table is initally empty, what harm is there in locking the
> > table?
>
Alon Goldshuv wrote:
> 9) allow for Simon's WAL bypass.
>
> I have surely missed some problems that hide behind the idea, but these
> points make me believe that LOAD DATA is a good idea.
The community is unlikely to add a new LOAD DATA command that does
_almost_ everything COPY does. We are muc
On Wed, 1 Jun 2005, Robert Treat wrote:
Funny how things come full circle... in previous threads someone mentioned a
few low hanging fruit items, we should start there, and maybe get one of the
more hard-core hackers to go through the TODO list and mark up some other
items.
My take on the ment
On Wed, 2005-06-01 at 15:50 -0500, Meredith L. Patterson wrote:
> Marc G. Fournier wrote:
> > Do we have any 'students' that are already up to speed, enough so that
> > they'd be able to accomplish something significant over a 2-3 month period?
>
> Well, I suppose now might be a good time to de-lu
Jochem van Dieten wrote:
> On 6/1/05, Bruce Momjian wrote:
> > Jochem van Dieten wrote:
> >>
> >> Why only on an empty table? What is the problem with bypassing WAL on
> >> any table as long as all files of that table are fsync'ed before
> >> commit?
> >
> > Because adding rows to a table might mo
'k, since there appears to be interest, I've tried to read a bit more up
on it, specifically the FAQs ... seems simple enough, but someone else may
have found a link that I haven't ...
Basically, developer (ie. Ramy Hassan) would go to:
http://code.google.com/soc_application.html
Fi
Funny how things come full circle... in previous threads someone mentioned a
few low hanging fruit items, we should start there, and maybe get one of the
more hard-core hackers to go through the TODO list and mark up some other
items.
My take on the mentor thing was that the students could p
Marc G. Fournier wrote:
> Do we have any 'students' that are already up to speed, enough so that
> they'd be able to accomplish something significant over a 2-3 month period?
Well, I suppose now might be a good time to de-lurk. Hi, my name's
Meredith, I'm a PhD student at the University of Iowa, I
On Wed, 2005-06-01 at 14:14 -0400, Tom Lane wrote:
> So what I'm thinking is we need no special WAL entries for this. What
> we need is just an operating mode of COPY in which it doesn't WAL-log
> its inserts, but instead fsyncs before completion, much like index build
> does. For safety it must
On Wed, 1 Jun 2005, Marc G. Fournier wrote:
One concern that was raised off of this list was the steep learning curve to
start with, to get to the point of beign able to do anything ...
Do we have any 'students' that are already up to speed, enough so that they'd
be able to accomplish somet
On Wed, 2005-06-01 at 14:24 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote:
> >> We're holding the table lock and will continue to do so until end of
> >> transaction. No transaction with an earlier id will ever se
Hannu,
> RAID10
>
> "Throughput report Y-axis is type of test X-axis is number of processes"
> "Record size = 8 Kbytes "
> "Output is in ops/sec"
> " Initial write "1352.90
> "Rewrite " 413.31
> RAID5
>
> "Throughput report Y-axis is type of test X-axis is number of processes"
Not sure about the current 'students'. I need to take a look and see
what kind of somewhat easy stuff is on the TODO (I haven't seen it in
awhile).
I like your suggestion for the mailing list.
Marc G. Fournier wrote:
One concern that was raised off of this list was the steep learning
curv
Greg Stark <[EMAIL PROTECTED]> writes:
> It occurs to me that at least on some OSes the WAL logs are being synced with
> O_SYNC or its ilk. In those cases the writes should be guaranteed to be
> written out in the order postgres wrote them. So if the tail end of the WAL
> entry is there (is there a
It occurs to me that at least on some OSes the WAL logs are being synced with
O_SYNC or its ilk. In those cases the writes should be guaranteed to be
written out in the order postgres wrote them. So if the tail end of the WAL
entry is there (is there any sort of footer?) then the entire entry must
One concern that was raised off of this list was the steep learning curve
to start with, to get to the point of beign able to do anything ...
Do we have any 'students' that are already up to speed, enough so that
they'd be able to accomplish something significant over a 2-3 month
period?
O
Are there any restrictions on 'mentor groups'? For instance, could we
create a 'mentors' mailing list, closed subscriptions, that contained
those willing to actively mentor, so that those being mentor'd have
multiple ppl's knowledge's to feed upon?
On Wed, 1 Jun 2005, Jonah H. Harris wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote:
>> We're holding the table lock and will continue to do so until end of
>> transaction. No transaction with an earlier id will ever see the data we
>> load because of the lock.
> Suppose you l
My participation would be limited to the actual number of newcomers. I
feel comfortable helping 2 or 3 people; any more than that would impact
my clients and consulting time. Although, it would never hurt to have
additional mentors :).
Robert Treat wrote:
We have a whole TODO list of poten
Simon Riggs <[EMAIL PROTECTED]> writes:
> If the server crashes, we replay WAL. If we see a load start message, we
> truncate the relation and note that a load has started. If there is WAL
> data for the tuples, we replay it. If WAL replay ends without the load
> transaction having successfully com
On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote:
> On Wed, 2005-06-01 at 11:55 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > 4. Optionally, we set a flag on the table showing the whole table is
> > > frozen. Anybody writing to this table subsequently will spoi
I think we definitely should submit PostgreSQL to Google.
Oleg
On Wed, 1 Jun 2005, Jonah H. Harris wrote:
Marc,
If you wanted to submit PostgreSQL to Google for this, I'd be willing to work
with any potentials. Should someone choose to work on PostgreSQL projects,
the money can go t
We have a whole TODO list of potential items for people to work on, and we
have several member of this list that work for universities in some capacity,
so istm we ought to give it a shot. I would think this is something that the
foundation would be good to be involved in as well, as it would c
On Wed, 2005-06-01 at 11:55 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > 4. Optionally, we set a flag on the table showing the whole table is
> > frozen. Anybody writing to this table subsequently will spoil this flag.
> > If the flag is set, all forms of VACUUM will return
I have been working on improving the COPY command performance and as a
result also came up with other thoughts that may possibly be better off
implemented in a new command (i.e LOAD DATA) rather than adding them to the
existing COPY.
The improvements I made were in the COPY parsing logic - changin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> - it is an option to COPY and CREATE TABLE AS, not GUC, not ALTER TABLE
AFAICS it could just happen automatically for CREATE TABLE AS; there's
no need for an option there, any more than there is for CREATE INDEX.
The only reason it needs to be an expli
On Wed, Jun 01, 2005 at 06:00:28PM +0100, Simon Riggs wrote:
> On Wed, 2005-06-01 at 11:31 -0400, Tom Lane wrote:
> > Perhaps it could work to use an ALTER TABLE command to flip the state.
> > But I'm not really seeing the point compared to treating it as a COPY
> > option. I do not believe that
On Wed, 2005-06-01 at 11:31 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I think this should be a decision done when creating a table, just like
> > TEMP tables. So you always know if a certain table is or is not
> > safe/replicated/recoverable.
> > This has also the advan
> > Why not just use the pid in teh name, and have one segment
> per backend?
>
> Being used only for signals you mean? That might work.
That was my idea. We'll end up using three global namespace objects
(mutex+event+shared memory) instead of one (named pipe), but as we're
not talking thousand
On 6/1/05, Bruce Momjian wrote:
> Jochem van Dieten wrote:
>>
>> Why only on an empty table? What is the problem with bypassing WAL on
>> any table as long as all files of that table are fsync'ed before
>> commit?
>
> Because adding rows to a table might modify existing pages, and if the
> COPY fa
Simon Riggs <[EMAIL PROTECTED]> writes:
> 4. Optionally, we set a flag on the table showing the whole table is
> frozen. Anybody writing to this table subsequently will spoil this flag.
> If the flag is set, all forms of VACUUM will return success immediately
> without performing a scan (since it i
Bruce Momjian writes:
> Jochem van Dieten wrote:
>> Why only on an empty table? What is the problem with bypassing WAL on
>> any table as long as all files of that table are fsync'ed before
>> commit?
> Because adding rows to a table might modify existing pages, and if the
> COPY fails, you have
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I think this should be a decision done when creating a table, just like
> TEMP tables. So you always know if a certain table is or is not
> safe/replicated/recoverable.
> This has also the advantage of requiring no changes to actual COPY and
> INSERT comm
On Wed, 2005-06-01 at 10:18 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Not unless you are proposing to change COPY to acquire a lock strong
> >> enough to lock out other writers to the table for the duration ...
>
> > Well, if the table is initally empty, what harm is
Marc,
If you wanted to submit PostgreSQL to Google for this, I'd be willing to
work with any potentials. Should someone choose to work on PostgreSQL
projects, the money can go to the group.
If anyone sees a problem with submitting under the PostgreSQL Global
Development Group, I can do it u
On Wed, Jun 01, 2005 at 10:27:04AM -0400, Brusser, Michael wrote:
>
> Our customer is running Postgresql v. 7.3.4 on Linux(Redhat 3.0 Ent.)
> The application crashed and I am trying to understand what could have caused
> this kind of problems:
>
>fdatasync of log file 0, segment 2 failed: inp
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> Nithin Sontineni wrote:
>> i want to know how postgres will store a
>> relation in pages and where can i see the code related
>> to this in the source code.Plz help me .
> You can find the code in src/backend/storage.
Also, re
"Brusser, Michael" <[EMAIL PROTECTED]> writes:
> Our customer is running Postgresql v. 7.3.4 on Linux(Redhat 3.0 Ent.)
> The application crashed and I am trying to understand what could have caused
> this kind of problems:
>fdatasync of log file 0, segment 2 failed: input/output error
>PGS
On 6/1/05, Hans-Jürgen Schönig <[EMAIL PROTECTED]> wrote:
> Personally I don't think that it is a good idea to do that.
> People will tend to corrupt their systems because they want speed
> (sometimes without thinking about the consequences).
>
> I can only think of one scenario where nologging wo
In case nobody has seen this:
http://code.google.com/summerofcode.html
Might be something to help fun, say, the GiST stuff? Just need to find a
student that could be mentor'd/directed/brought up to speed?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.o
> Could we keep track of NOT TODO items also?
>
> The question is where do you put this idea if you reject it? :-)
>
And of course a link to the thread, or an explanation on why it was
rejected. That way if someone can solve the reason for reject it maybe
a new discussion can be made.
--
regard
Zahid Khan <[EMAIL PROTECTED]> writes:
> I want to know that does ODBC executes all statement
> as simple query as i have't found any thing as
> parse/bind/execute messeges in ODBC case.
Probably; the ODBC code long predates the V3 protocol, and I don't think
it's been updated. But you're asking
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Why not just use the pid in teh name, and have one segment per backend?
Being used only for signals you mean? That might work.
I dislike fooling around with the contents of postmaster.pid, as that
will inject platform-specific code into places wher
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I've started working on this change, and one difference has shown up
> immediately in the regression tests. v8.0.3 currently returns:
>SELECT INTERVAL '10 years -11 month -12 days +13:14' AS "9 years...";
>9 years...
>-
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Jun 1, 2005, at 1:42 PM, Michael Glaesemann wrote:
>> -- v8.0.3
>> test=# select '25 hours'::interval;
>> interval
>>
>> 1 day 01:00:00
>> (1 row)
>>
>> -- new interval code
>> test=# select '25 hours'::interval;
>> interval
>> -
Title: fdatasync failed, I/O error
Our customer is running Postgresql v. 7.3.4 on Linux(Redhat 3.0 Ent.)
The application crashed and I am trying to understand what could have caused this kind of problems:
fdatasync of log file 0, segment 2 failed: input/output error
PGSTAT: Error clo
On Wed, Jun 01, 2005 at 10:12:34AM -0400, Tom Lane wrote:
> "Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> > I also noticed your comment above that mentioned that compression would be
> > less effective as the pages became more full. Would changing the loading
> > factor of database pages have an
Bruce Momjian writes:
> Tom Lane wrote:
>> Not unless you are proposing to change COPY to acquire a lock strong
>> enough to lock out other writers to the table for the duration ...
> Well, if the table is initally empty, what harm is there in locking the
> table?
You cannot *know* whether it is
Jochem van Dieten wrote:
> On 01 Jun 2005 04:44:24 -0400, Greg Stark wrote:
> > Greg Stark writes:
> >>
> >> For CREATE TABLE AS in the non-PITR case you don't really need to WAL log
> >> the
> >> records at all. If it fails in the middle you just drop the table. When it
> >> completes you do a c
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Sorry to followup to my own message, but it occurs to me that COPY could be
> > made to automatically do this for the case of an empty destination table
> > too.
>
> Not unless you are proposing to change COPY to acquire a lock strong
>
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> I also noticed your comment above that mentioned that compression would be
> less effective as the pages became more full. Would changing the loading
> factor of database pages have an effect here, as I would have thought that
> the WAL would be fsyn
On 01 Jun 2005 04:44:24 -0400, Greg Stark wrote:
> Greg Stark writes:
>>
>> For CREATE TABLE AS in the non-PITR case you don't really need to WAL log the
>> records at all. If it fails in the middle you just drop the table. When it
>> completes you do a checkpoint before acknowledging the COMMIT.
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> I'm still a little nervous about dropping down to CRC32 from CRC64 and so
> was just wondering what the net saving would be using one CRC64 across the
> whole WAL record?
None to speak of; the startup/teardown time is trivial. It's the
per-byte cos
Simon Riggs <[EMAIL PROTECTED]> writes:
> If I/O is a problem, then surely you will agree that PreAllocXLog is
> still required and should not be run by a backend?
It is still required, but it isn't run by backends --- it's fired off
during checkpoints. I think there was some discussion recently
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2005-06-01 at 16:34 +0800, Christopher Kings-Lynne wrote:
> There are some other arguments in favour of a LOAD command Alon?
>>
>> We already have LOAD, so you'll have to choose something else :)
> Its annoying, I grant you. :-)
> LOAD 'libra
Greg Stark <[EMAIL PROTECTED]> writes:
> Sorry to followup to my own message, but it occurs to me that COPY could be
> made to automatically do this for the case of an empty destination table too.
Not unless you are proposing to change COPY to acquire a lock strong
enough to lock out other writers
Simon Riggs <[EMAIL PROTECTED]> writes:
> Where I'm leading to is this: If the physical tlist optimization is a
> considerable gain, and it required OIDs, then changing the system
> default to WITHOUT OIDS will cause us to lose the optimization. Yes?
It doesn't require OIDs, though. What it requi
Simon Riggs wrote:
> On Wed, 2005-06-01 at 04:44 -0400, Greg Stark wrote:
> > Greg Stark <[EMAIL PROTECTED]> writes:
> >
> > > For CREATE TABLE AS in the non-PITR case you don't really need to WAL log
> > > the
> > > records at all. If it fails in the middle you just drop the table. When it
> > >
On Wed, 1 Jun 2005, Marc G. Fournier wrote:
On Wed, 1 Jun 2005, Oleg Bartunov wrote:
We'd love to start tomorrow working on GiST, but we have some current
obligations we need to sort out.
It will probably take more then a day to do fund raising, which is what
Christopher is suggesting ... b
[EMAIL PROTECTED] ("Jeffrey W. Baker") wrote:
> On Mon, 2005-05-30 at 21:38 -0700, Luke Lonergan wrote:
> After reading this very comprehensive benchmark:
>
> http://print.tweakers.net/?reviews/557
>
> I purchased one of the Areca controllers with a large battery-backed
> cache. It is unholy fast.
Josh Berkus wrote:
> Bruce,
>
> > > >Added to TODO:
> > > >
> > > >* Add the features of packages
> > > > o Make private objects accessable only to objects in the same
> > > > schema
> > > > o Allow current_schema.objname to access current schema objects
> > > > o Add se
On Wed, 1 Jun 2005, Oleg Bartunov wrote:
We'd love to start tomorrow working on GiST, but we have some current
obligations we need to sort out.
It will probably take more then a day to do fund raising, which is what
Christopher is suggesting ... but they need some sort of 'value' for a
goal
On K, 2005-06-01 at 14:00 +0200, Dawid Kuroczko wrote:
> On 6/1/05, Zeugswetter Andreas DAZ SD <[EMAIL PROTECTED]> wrote:
> > You could create a separate bufferpool per page size. Of course that
> > has other disadvantages.
> >
> > Is it really so difficult to create and attach another shmem segme
On K, 2005-06-01 at 00:01 +0100, Simon Riggs wrote:
> Recent test results have shown a substantial performance improvement
> (+25%) if WAL logging is disabled for large COPY statements. This is to
> be expected, though has a price attached: losing the ability to crash
> recover data loaded in this
On Wed, 2005-06-01 at 04:44 -0400, Greg Stark wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
> > For CREATE TABLE AS in the non-PITR case you don't really need to WAL log
> > the
> > records at all. If it fails in the middle you just drop the table. When it
> > completes you do a checkpoint be
1 - 100 of 120 matches
Mail list logo
