Robert Haas wrote:
On Wed, Sep 16, 2009 at 6:05 PM, Josh Berkus j...@agliodbs.com wrote:
Now that Simon has submitted this, can some of the heavy-hitters here
review it? Heikki?
Nobody's name is next to it.
I don't think anyone is planning to ignore this patch, but it wasn't
included in
On Wed, 2009-09-16 at 23:12 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-09-16 at 21:48 -0400, Tom Lane wrote:
Yeah, I was just wondering about that myself. Seems like there would
be lots of situations where short exclusive-lock intervals could be
tolerated,
On Thu, 2009-09-17 at 09:54 +0300, Heikki Linnakangas wrote:
This is a pretty small CommitFest, so there
shouldn't be any shortage of reviewers, though Heikki's time may be
stretched a little thin, since Streaming Replication is also in the
queue, and he is working on index-only scans.
On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
What we need is VACUUM FULL CONCURRENTLY and REINDEX CONCURRENTLY.
VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
possible doesn't make it so.
It depends on what do you mean
Fujii Masao wrote:
On Tue, Sep 15, 2009 at 7:53 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
After playing with this a little bit, I think we need logic in the slave
to reconnect to the master if the connection is broken for some reason,
or can't be established in the
On Thu, Sep 17, 2009 at 10:08, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Tue, Sep 15, 2009 at 7:53 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
After playing with this a little bit, I think we need logic in the slave
to reconnect
Tom Lane wrote:
psql has MORE need to support old syntax than the backend does, because
it's supposed to work against old servers.
I wonder though if we couldn't simplify matters. Offhand it seems to me
that psql doesn't need to validate the command's syntax fully. All it
really needs to
Pavel,
I am not sure about syntax change. Isn't better solve this problem
well. This is too simple solution. I thinking, so we able to add new
parser for COPY statement and share this paraser between SQL and psql.
Refactoring COPY to put new parsers seems to be another project. The
idea here
Some random comments:
I don't think we need the new PM_SHUTDOWN_3 postmaster state. We can
treat walsenders the same as the archive process, and kill and wait for
both of them to die in PM_SHUTDOWN_2 state.
I think there's something wrong with the napping in walsender. When I
perform
Tom Lane wrote:
While I understand the need for the server to still support the syntax,
is it necessary for newer version of psql to support the old syntax?
psql has MORE need to support old syntax than the backend does, because
it's supposed to work against old servers.
Well, I wonder
On Thu, 2009-09-17 at 10:08 +0200, Heikki Linnakangas wrote:
Robert Haas suggested a while ago that walreceiver could be a
stand-alone utility, not requiring postmaster at all. That would allow
you to set up streaming replication as another way to implement WAL
archiving. Looking at how the
2009/9/17 Emmanuel Cecchet m...@asterdata.com:
Tom Lane wrote:
While I understand the need for the server to still support the syntax,
is it necessary for newer version of psql to support the old syntax?
psql has MORE need to support old syntax than the backend does, because
it's supposed
Pavel Stehule wrote:
Well, I wonder how many users just upgrade psql vs upgrade the server. I was
thinking that when users perform a database upgrade their application often
remain the same and therefore the server needs to support the old syntax.
Unless you are upgrading a machine where a bunch
On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut pete...@gmx.net wrote:
Well, in such cases it may be useful to add an option such as --oknodo
to select the idempotent behavior.
It took me about 60 seconds to figure out what I thought you were
going for there, so I submit that's not a good
On Wed, Sep 16, 2009 at 09:48:20PM -0400, Tom Lane wrote:
Seems like there would
be lots of situations where short exclusive-lock intervals could be
tolerated, even though not long ones. So that's another argument
for being able to set an upper bound on how many tuples get moved
per call.
Emmanuel Cecchet m...@asterdata.com wrote:
I just wonder how many users are using a single psql to manage
multiple server instances of different older versions.
I do that, but I do try to keep all the active versions on my machine,
so that I can use one which exactly matches any of our 100
On Thu, Sep 17, 2009 at 9:35 AM, Joshua Tolley eggyk...@gmail.com wrote:
On Wed, Sep 16, 2009 at 09:48:20PM -0400, Tom Lane wrote:
Seems like there would
be lots of situations where short exclusive-lock intervals could be
tolerated, even though not long ones. So that's another argument
for
2009/9/17 Emmanuel Cecchet m...@asterdata.com:
Pavel Stehule wrote:
Well, I wonder how many users just upgrade psql vs upgrade the server. I
was
thinking that when users perform a database upgrade their application
often
remain the same and therefore the server needs to support the old
Emmanuel Cecchet m...@asterdata.com writes:
Tom Lane wrote:
psql has MORE need to support old syntax than the backend does, because
it's supposed to work against old servers.
Well, I wonder how many users just upgrade psql vs upgrade the server.
We have established a project policy that
Hannu Krosing ha...@2ndquadrant.com writes:
On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
possible doesn't make it so.
It depends on what do you mean by VACUUM FULL
Anything that moves tuples is not acceptable as a
On Thu, 2009-09-17 at 09:45 -0400, Robert Haas wrote:
On Thu, Sep 17, 2009 at 9:35 AM, Joshua Tolley eggyk...@gmail.com wrote:
On Wed, Sep 16, 2009 at 09:48:20PM -0400, Tom Lane wrote:
Seems like there would
be lots of situations where short exclusive-lock intervals could be
tolerated,
On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
possible doesn't make it so.
It depends on what do you mean by VACUUM
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote:
because it will break applications that depend on CTID.
Do you know of any such applications out in the wild ?
Yes, they're out there.
regards, tom lane
--
Sent via
Tom Lane wrote:
Emmanuel Cecchet m...@asterdata.com writes:
Tom Lane wrote:
psql has MORE need to support old syntax than the backend does, because
it's supposed to work against old servers.
Well, I wonder how many users just upgrade psql vs upgrade the server.
We have
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-17 at 09:45 -0400, Robert Haas wrote:
Making the code more complicated so that it's easier to tune something
that isn't very hard to tune anyway doesn't seem like a good
trade-off.
I think that just making sure that pessimal cases
Emmanuel Cecchet m...@asterdata.com writes:
Does that mean that we can drop the 7.3 syntax or should we just keep it?
I wouldn't object to dropping the 7.3 syntax now, especially if we're
about to introduce a new syntax and deprecate the old one ...
regards, tom lane
--
Tom Lane wrote:
I wonder though if we couldn't simplify matters. Offhand it seems to me
that psql doesn't need to validate the command's syntax fully. All it
really needs to do is find the target filename and replace it with
STDIN/STDOUT. Could we have it just treat the remainder of the line
Just been looking again at the way FSM works. In fsm_search_avail() we
essentially have just a single way for working out how to search the
tree.
Seems like it would be good to abstract this so that we can implement a
number of FSM search strategies
* (current) randomize - page selection
On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
possible doesn't make it so.
It depends on what do you
On Thu, 2009-09-17 at 10:45 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-17 at 09:45 -0400, Robert Haas wrote:
Making the code more complicated so that it's easier to tune something
that isn't very hard to tune anyway doesn't seem like a good
On Thu, 2009-09-17 at 11:25 -0400, Robert Haas wrote:
On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
Following a discussion on the pgsql-admin list
http://archives.postgresql.org/pgsql-admin/2009-09/msg00075.php, I have
created a patch to (optionally) allow PostgreSQL to do a LDAP search to
determine the user's DN (as is done in Apache, MediaWiki, Bugzilla, et al.)
instead of building the DN
Robert Haas wrote:
On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
possible doesn't make it so.
It
On Mon, Sep 14, 2009 at 2:07 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2009-08-17 at 10:22 -0400, Tom Lane wrote:
As always with patches that are meant to improve performance,
some experimental evidence would be a good thing.
I haven't had time to performance test this patch yet, and
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Anything that moves tuples is not acceptable as a hidden background
operation, because it will break applications that depend on CTID.
I'm a
On Thu, 2009-09-17 at 10:32 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote:
because it will break applications that depend on CTID.
Do you know of any such applications out in the wild ?
Yes, they're out there.
How
Jeff Janes jeff.ja...@gmail.com writes:
Does the community think that experimental performance testing is a
must-have in order for this patch to be acceptable?
Dunno about others, but I think so. It's complicating both the
implementation and the users-eye view of VACUUM, and I want more than
a
Simon Riggs si...@2ndquadrant.com writes:
The update utility being discussed is in danger of confusing these two
goals
* compact the table using minimal workspace
* compact the table with minimal interruption to concurrent updaters
Actually, the update utility is explicitly meant to satisfy
On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Anything that moves tuples is not acceptable as a hidden background
operation, because
On Thu, Sep 17, 2009 at 12:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's no different from the situation where another backend UPDATEs the
row under your nose, but it's not something you want to do automatically
without notice.
Exactly. The application is typically going to throw a
On Thu, Sep 17, 2009 at 12:31 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
Exactly. The application is typically going to throw a concurrent
update type of error when this happens, and we don't want magic
background operations to cause that.
Would'nt current VACUUM FULL or CLUSTER cause
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote:
Or for an update without having to hold a transaction open. We have
recommended this type of technique in the past:
If you need real locking, then just define a locked (or locked_by or
On Thu, Sep 17, 2009 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Does the community think that experimental performance testing is a
must-have in order for this patch to be acceptable?
Dunno about others, but I think so. It's complicating both the
Peter Eisentraut pete...@gmx.net wrote:
I think it's important to consider what the conforming behavior
really achieves in practice. The INFO section is essential nowadays
for correct functioning on a large portion of distributions. The
exit codes are relatively uninteresting but
On Thu, 2009-09-17 at 12:30 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The update utility being discussed is in danger of confusing these two
goals
* compact the table using minimal workspace
* compact the table with minimal interruption to concurrent updaters
Selena Deckelmann wrote:
On Thu, Sep 3, 2009 at 9:00 AM, Robert Haasrobertmh...@gmail.com wrote:
Yeah, I'm game, though I'm hoping not to become the guy who spends all
his time doing release planning, because I like writing code, too.
Hopefully Selena won't mind my mentioning that she
On Thu, 2009-09-17 at 12:36 -0400, Robert Haas wrote:
Despite my recent screw-up in this department, it should really be the
patch author's responsibility to test the patch first. Then the
reviewing process can involve additional testing. So I would say this
should be moved to Returned With
On Thu, Sep 17, 2009 at 18:02, Robert Fleming flemi...@gmail.com wrote:
Following a discussion on the pgsql-admin list
http://archives.postgresql.org/pgsql-admin/2009-09/msg00075.php, I have
created a patch to (optionally) allow PostgreSQL to do a LDAP search to
determine the user's DN (as is
On Thu, 17 Sep 2009, Peter Eisentraut wrote:
On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote:
Well, with differences in behavior, of course, like attempting a fast
shutdown, and escalating to an immediate shutdown if that doesn't
succeed in the allowed time.
Right, but if you think
[Thanks for the heads up about the MessageID missing when posting this
previously. Was doing some mail filter development, and accidentally
left it in place... ]
Magnus Hagander wrote:
2009/8/25 Alvaro Herrera alvhe...@commandprompt.com:
Something to keep in mind -- my getifaddrs(3) manpage
Josh Berkus wrote:
Hackers,
Per discussions on two other threads on this list which have apparently
reached consensus, we will be going with the following schedule:
CF1 7/15 to 8/14
Alpha1by 8/20
CF2 9/15 to 10/14
Alpha2by 10/20
CF3 11/15 to 12/14
Alpha3
On Wed, 16 Sep 2009, Tom Lane wrote:
* Shrink a table in place - when no space available
To be addressed by the UPDATE-style tuple-mover (which could be thought
of as VACUUM FULL rewritten to not use any special mechanisms).
Is there any synergy here with the needs of a future in-place
On Thu, 2009-09-17 at 12:36 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote:
Or for an update without having to hold a transaction open. We have
recommended this type of technique in the past:
If you need real
On Thu, 2009-09-17 at 14:33 -0400, Greg Smith wrote:
On Wed, 16 Sep 2009, Tom Lane wrote:
* Shrink a table in place - when no space available
To be addressed by the UPDATE-style tuple-mover (which could be thought
of as VACUUM FULL rewritten to not use any special mechanisms).
Is there
On Thu, Sep 17, 2009 at 11:07:33AM -0400, Emmanuel Cecchet wrote:
Tom Lane wrote:
I wonder though if we couldn't simplify matters. Offhand it seems to me
that psql doesn't need to validate the command's syntax fully. All it
really needs to do is find the target filename and replace it with
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
On Thu, Sep 17, 2009 at 11:07:33AM -0400, Emmanuel Cecchet wrote:
Tom Lane wrote:
I wonder though if we
On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote:
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
Hooray, that works just fine now. I guess I
Hi,
Forewords: re-reading, I hope my english will not make this sound like a
high-kick when I'm just struggling to understand what all this is
about. Sending in order not to regret missing the oportunity I think I'm
seeing...
Tom Lane t...@sss.pgh.pa.us writes:
Hannu Krosing
Attached patch extends pg_ctl command with init option.
pg_ctl -D /var/lib/postgres [-s] init
This should replace usage of initdb command which has problematic name
as we already discussed several times. Initdb binary will be still
there, but it can be renamed and move into execlib dir in the
On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote:
Attached patch extends pg_ctl command with init option.
pg_ctl -D /var/lib/postgres [-s] init
This should replace usage of initdb command which has problematic name
as we already discussed several times. Initdb binary will be still
On tor, 2009-09-17 at 09:26 -0400, Robert Haas wrote:
On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut pete...@gmx.net wrote:
Well, in such cases it may be useful to add an option such as --oknodo
to select the idempotent behavior.
It took me about 60 seconds to figure out what I thought
On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
Well, in such cases it may be useful to add an option such as
--oknodo to select the idempotent behavior.
I found that confusing (as did Robert); how about --lsm-conforming?
s/lsm/lsb/
I'm not so sure that I would label it as LSB,
On tor, 2009-09-17 at 14:21 -0400, Greg Smith wrote:
I've implemented exactly the same logic Kevin describes for a past
consulting customer and for multiple forms of shutdown scripts at
Truviso.
I would suggest the situation here is that it's so easy to script a
custom
solution that the
On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote:
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
Emmanuel,
Thanks for getting
On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
Well, in such cases it may be useful to add an option such as
--oknodo to select the idempotent behavior.
I found that confusing (as did Robert); how about
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 15, 2009 at 9:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Here we go again. Following Tom's advice to not insert crocks in
add_path(), I've instead introduced a noopjoin path type which ignores
its
Here you go.
Emmanuel
Dan Colish wrote:
On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote:
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
Magnus Hagander wrote:
On Thu, Sep 3, 2009 at 13:31, Andrew Dunstanand...@dunslane.net wrote:
Magnus Hagander wrote:
Oh, hang on, the NULL string refers to the copy parameter? Not a
part of the data? I read it as a string being NULL. Maybe something
like the value of the NULL string
On Thu, Sep 17, 2009 at 4:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 15, 2009 at 9:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Here we go again. Following Tom's advice to not insert crocks in
momj...@postgresql.org (Bruce Momjian) writes:
Log Message:
---
CVS NULL Documentation
Clearify documentation of CVS's output of NULL values, per suggestion
from Magnus.
This has not clarified anything; what it has done is transformed
correct statements into incorrect ones. You
--On 17. September 2009 23:00:12 +0300 Peter Eisentraut pete...@gmx.net
wrote:
f the name is a problem, why not change the name? What you are
proposing above is effectively a very elaborate name change, so why not
go for a simpler one?
I don't like the solution by using -o initdb options
On Thu, Sep 17, 2009 at 5:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
momj...@postgresql.org (Bruce Momjian) writes:
Log Message:
---
CVS NULL Documentation
Clearify documentation of CVS's output of NULL values, per suggestion
from Magnus.
This has not clarified anything; what it
Bruce Momjian wrote:
Magnus Hagander wrote:
On Thu, Sep 3, 2009 at 13:31, Andrew Dunstanand...@dunslane.net wrote:
Magnus Hagander wrote:
Oh, hang on, the NULL string refers to the copy parameter? Not a
part of the data? I read it as a string being NULL. Maybe something
like
On ons, 2009-09-16 at 10:54 +0530, Abhijit Menon-Sen wrote:
I can't help but think that it would be nice to report the default value
of a parameter that is reset (i.e. parameter $x reset to default value
$y). The first attached patch does this by calling GetConfigOption()
after the value has
Hannu Krosing ha...@2ndquadrant.com writes:
But maybe something can be tahen from this discussion the other way
round - maybe we should not be afraid of doing null updates during
in-place update
The problem for in-place update is that it can't assume that any of the
normal infrastructure (like
Dimitri Fontaine dfonta...@hi-media.com writes:
I don't see any reason why not breaking the user visible behavior of
tuples CTID between any two major releases,
Am I completely wet here?
Completely. This is a user-visible behavior that we have encouraged
people to rely on, and for which
Andrew Dunstan wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
On Thu, Sep 3, 2009 at 13:31, Andrew Dunstanand...@dunslane.net wrote:
Magnus Hagander wrote:
Oh, hang on, the NULL string refers to the copy parameter? Not a
part of the data? I read it as a
Tom Lane t...@sss.pgh.pa.us writes:
Completely. This is a user-visible behavior that we have encouraged
people to rely on, and for which there is no easy substitute.
Excited to have self-healing tables (against bloat), I parse this as an
opening. Previously on this thread you say:
(Actually,
Tom Lane wrote:
momj...@postgresql.org (Bruce Momjian) writes:
Log Message:
---
CVS NULL Documentation
Clearify documentation of CVS's output of NULL values, per suggestion
from Magnus.
This has not clarified anything; what it has done is transformed
correct statements
Hi,
I have read through the patch a few times and it looks OK. The
additions to the COPY syntax work as expected and as agreed upon
based on the thread. Below are some points from my checklist.
- Patch applies cleanly
- Included new tests and documentation
Tom Lane wrote:
I hope that the bug will get fixed in due course, but even if they
respond pretty quickly it will be years before the problem disappears
from every copy of gcc in the field. So I'm thinking that it would
behoove us to install a workaround, now that we've characterized the
On Thu, Sep 17, 2009 at 09:56:44AM +0900, Michael Paquier wrote:
Hi all,
Sorry for my late reply.
There is no other update for this patch since the 13th of August, at least
until today. The new patch is attached
By the way I worked on the comments that Dan and Gabriel pointed out.
I added
On Thu, 17 Sep 2009, Dan Colish wrote:
- Performance appears to be the same although I don't have a good way
for
testing this at the moment
Here's what I do to generate simple COPY performance test cases:
CREATE TABLE t (i integer);
INSERT INTO t SELECT x FROM
On Thu, Sep 17, 2009 at 2:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
On Wed, Sep 16, 2009 at 6:05 PM, Josh Berkus j...@agliodbs.com wrote:
Now that Simon has submitted this, can some of the heavy-hitters here
review it? Heikki?
Nobody's name is
On Thu, Sep 17, 2009 at 6:54 PM, Greg Smith gsm...@gregsmith.com wrote:
On Thu, 17 Sep 2009, Dan Colish wrote:
- Performance appears to be the same although I don't have a good
way for
testing this at the moment
Here's what I do to generate simple COPY performance test
Greg Smith wrote:
On Thu, 17 Sep 2009, Dan Colish wrote:
- Performance appears to be the same although I don't have a good
way for
testing this at the moment
Here's what I do to generate simple COPY performance test cases:
CREATE TABLE t (i integer);
INSERT INTO t SELECT x FROM
On Thu, Sep 17, 2009 at 07:10:35PM -0400, Andrew Dunstan wrote:
Greg Smith wrote:
On Thu, 17 Sep 2009, Dan Colish wrote:
- Performance appears to be the same although I don't have a good
way for
testing this at the moment
Here's what I do to generate simple COPY performance
On that particular patch, as Robert mentioned, only the parsing has changed.
In the case of \copy, the parsing is much lighter than before in psql
(remains the same in the server). The bigger the COPY operation the less
you will see the impact of the parsing since it is done only once for
the
Dan Colish wrote:
CREATE TABLE
INSERT 0 10
Timing is on.
COPY 10
Time: 83.273 ms
BEGIN
Time: 0.412 ms
TRUNCATE TABLE
Time: 0.357 ms
COPY 10
Time: 140.911 ms
COMMIT
Time: 4.909 ms
On Thu, Sep 17, 2009 at 07:45:45PM -0400, Andrew Dunstan wrote:
Dan Colish wrote:
CREATE TABLE
INSERT 0 10
Timing is on.
COPY 10
Time: 83.273 ms
BEGIN
Time: 0.412 ms
TRUNCATE TABLE
Time: 0.357 ms
COPY 10
Time: 140.911
On Thu, Sep 17, 2009 at 8:31 PM, Dan Colish d...@unencrypted.org wrote:
Ok, so I ran something like you suggested and did a simple copy from an
empty file to just test the parsing. I have the COPY statement run 3733
times in the transaction block and did the select timestamps, but I
still only
On Tue, Sep 15, 2009 at 07:38:18AM +0200, Pavel Stehule wrote:
it isn't fair :) why you use $$ without single quote? And still this
case should be vulnerable on SQL injection. Maybe you or me knows,
what SQL injection means, but beginners knows nothing and this people
use following bad code:
Robert Haas wrote:
On Thu, Sep 17, 2009 at 8:31 PM, Dan Colish d...@unencrypted.org wrote:
Ok, so I ran something like you suggested and did a simple copy from an
empty file to just test the parsing. I have the COPY statement run 3733
times in the transaction block and did the select
On Thu, Sep 17, 2009 at 11:15 AM, Magnus Hagander mag...@hagander.netwrote:
On Thu, Sep 17, 2009 at 18:02, Robert Fleming flemi...@gmail.com wrote:
Following a discussion on the pgsql-admin list
http://archives.postgresql.org/pgsql-admin/2009-09/msg00075.php, I
have
created a patch to
I'm sorry for late my response.
I already sent same contents to Marcos, but I did not cc to all of yours.
(I'll join pgsql-hackers ML).
1. Statement of PGCluster-II
The state of PGCluster-II is re designing.
I developed and demonstorated PGCluster-II as full data shared model in 2006.
It worked
Simon Riggs si...@2ndquadrant.com wrote:
* compact - page selection specifically attempts to find the lowest
numbered blocks, so that the table will naturally shrink over time.
We cannot shrink the table if one tuple remains at the end of table
and the tuple is always HOT-updated, because we
I found a strange checks in the native database privilege stuff.
The EnableDisableRule() calls pg_class_ownercheck() to check
the ownership of the relation which has a rule to be turned
on/off.
Only ATExecEnableDisableRule() calls the EnableDisableRule(),
and only ATExecCmd() calls the
On Sun, Sep 13, 2009 at 10:32 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 11, 2009 at 12:09 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/8/10 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel
Excellent news,Mitani. My personal intention if to help you with this work for
the redesign of PGCluster-II, or on the coding of it.
If we work like a team, we can release this new version of the project more
quickly.
Do you have any sources repository of this new version? I work fine with CVS
On Thu, Sep 17, 2009 at 6:24 PM, Robert Fleming flemi...@gmail.com wrote:
The new patch ...
s/printf/ereport(LOG,/
1 - 100 of 104 matches
Mail list logo
