On Wednesday, October 24, 2012 12:15 AM Alvaro Herrera wrote:
Amit kapila wrote:
Rebased version of patch based on latest code.
Uhm, how can this patch change a caller of PageAddItem() by adding one
more argument, yet not touch bufpage.c at all? Are you sure this
compiles?
It compiles,
Is it possible to copy some table data from remote client to the PG database
server directly without upload the data file to the server side in advance?
---
ThanksRegards,
Xiong He
You can use the libpq API:
http://www.postgresql.org/docs/9.2/interactive/libpq-copy.html
The Postgresql JDBC driver exposes COPY, IIRC.
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Xiong He
Sent: Tuesday, October 23, 2012 11:55 PM
To:
On Wed, Oct 24, 2012 at 3:54 PM, Xiong He iih...@qq.com wrote:
Is it possible to copy some table data from remote client to the PG
database server directly without upload the data file to the server side in
advance?
With a psql client you can use the command ¥copy to perform that.
--
Michael
On 10/23/2012 04:13 PM, Tom Lane wrote:
[ hadn't been following this thread, sorry ]
Hannu Krosing ha...@2ndquadrant.com writes:
My RFC was for a proposal to skip writing the unneeded info in local
tables and put it _only_ in WAL.
This concept seems fundamentally broken. What will happen if
On 10/23/2012 06:47 PM, Robert Haas wrote:
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus j...@agliodbs.com wrote:
...
3. Double-down on #2 in a multithreaded environment.
For an application-level queue, the base functionality is:
ADD ITEM
READ NEXT (#) ITEM(S)
LOCK ITEM
DELETE ITEM
More
On 10/19/12 8:15 PM, Will Leinweber wrote:
This patch adds \watch to psql. It is much like the unix equivalent,
defaulting to every 2 seconds, and allowing you optionally specify a
number of seconds.
This doesn't handle multiline queries:
= \watch select 1 +
ERROR: 42601: syntax error at end
Guys,
May I remind everyone that we still have an commitfest open, which to
date has 23 patches needing some effort, and that this patch, while
probably very useful and interesting, belongs to the next commitfest
which is not yet in progress.
--
Álvaro Herrera
On 24 October 2012 15:24, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Guys,
May I remind everyone that we still have an commitfest open, which to
date has 23 patches needing some effort, and that this patch, while
probably very useful and interesting, belongs to the next commitfest
which
Thom Brown wrote:
On 24 October 2012 15:24, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Guys,
May I remind everyone that we still have an commitfest open, which to
date has 23 patches needing some effort, and that this patch, while
probably very useful and interesting, belongs to the
On Wed, Oct 24, 2012 at 12:36:31AM -0400, Tom Lane wrote:
The proposed patch uses this if the referencing column is an array:
SELECT 1 WHERE
(SELECT pg_catalog.count(DISTINCT y) FROM pg_catalog.unnest($1) y)
OPERATOR(pg_catalog.=)
(SELECT pg_catalog.count(*) FROM
(SELECT 1 FROM
On Wed, Oct 24, 2012 at 05:55:56AM +, Amit kapila wrote:
Wednesday, October 24, 2012 5:51 AM Noah Misch wrote:
Stepping back a moment, I would expect this patch to change performance in
at
least four ways (Heikki largely covered this upthread):
a) High-concurrency workloads will
Noah Misch n...@leadboat.com writes:
For FKs, we currently document that The referenced columns must be the
columns of a non-deferrable unique or primary key constraint in the referenced
table. Taking that literally, one might imagine that bare UNIQUE indexes do
not qualify. However,
Marco Nenciarini marco.nenciar...@2ndquadrant.it writes:
Please find the attached refreshed patch (v2) which fixes the loose ends
you found.
Attached is a v3 patch that updates the syntax per discussion, uses what
seems to me to be a saner (more extensible) catalog representation, and
contains
On Tue, Oct 16, 2012 at 12:24 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2012/10/16 Shigeru HANADA shigeru.han...@gmail.com:
Hi Pavel,
On Tue, Oct 16, 2012 at 6:59 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
here is updated patch, I moved lot of code from lexer to command.com,
Alvaro Herrera wrote:
There having been no updated patch yet, I have closed this as returned
with feedback. Thanks Noah!
Please make sure to submit an updated patch to the upcoming commitfest,
which is due to start in about three weeks.
Due to an hyperacute increase of workload in my day
On Tue, Oct 23, 2012 at 8:21 PM, Noah Misch n...@leadboat.com wrote:
-Patch- -tps@-c1- -tps@-c2- -tps@-c8- -WAL@-c8-
HEAD,-F80 816 164465281821 MiB
xlogscale,-F80 824 164365511826 MiB
xlogscale+lz,-F80 717
This problem has been discussed before. Those familiar with the subject
please skip the next paragraph.
When autovacuum finds a substantial amount of empty pages at the end of
a relation, it attempts to truncate it in lazy_truncate_heap(). Because
all the scanning had been done in parallel to
Here is the patch for it.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index c9253a9..9f880f0 100644
*** a/src/backend/commands/vacuumlazy.c
---
Peter Geoghegan escribió:
I think that we're both going to be busy next week, since we're both
attending pgconf.eu. For that reason, I would like to spend some time
tomorrow to get something in shape, that I can mark ready for
committer. I'd like to get this patch committed during this
On 24 October 2012 23:29, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Let me know if you think that that's a good idea.
I guess you didn't get around to it.
I did get some work on this done, which does change things somewhat.
In particular, I think that the need to have so many new fields
On Tue, Oct 23, 2012 at 08:21:54PM -0400, Noah Misch wrote:
-Patch- -tps@-c1- -tps@-c2- -tps@-c8- -WAL@-c8-
HEAD,-F80 816 164465281821 MiB
xlogscale,-F80 824 164365511826 MiB
xlogscale+lz,-F80 717 1466
Jan,
* Jan Wieck (janwi...@yahoo.com) wrote:
This problem has been discussed before. Those familiar with the
subject please skip the next paragraph.
Apologies if this was already thought-of and ruled out for some reason,
but...
Because all the scanning had been done in parallel to normal DB
Peter Geoghegan escribió:
On 24 October 2012 23:29, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Let me know if you think that that's a good idea.
I guess you didn't get around to it.
I did get some work on this done, which does change things somewhat.
In particular, I think that
24 matches
Mail list logo
