On Thu, 4 Nov 2010 18:22:52 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Thu, Nov 4, 2010 at 6:04 PM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
For example:
* PRIMARY ACCESS_METHOD - HANDLER of FOREIGN DATA WRAPPER
* am_scancost() - FdwRoutine.EstimateCosts()
On 04/11/10 20:43, Hannu Krosing wrote:
On Thu, 2010-11-04 at 11:07 -0600, Alex Hunsaker wrote:
On Thu, Nov 4, 2010 at 03:54, Hannu Krosing ha...@2ndquadrant.com wrote:
try:
plpy.execute(insert into foo values(1))
except plpy.UniqueViolation, e:
plpy.notice(Ooops, you got yourself a
Hello
I am looking on http://kputnam.github.com/piggly/ site. I am thinking,
so can be very easy write low level support to plpgsql. And this can
to solve a some issue of plpgsql with lazy SQL full checking.
A raising syntax error of some SQL inside plpgsql after a months of
production usage is
On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
* am_beginscan() - first call of FdwRoutine.Iterate()?
It might be good to have a separated beginscan method if we use
asynchronous scans in multiple foreign servers in one query
You mean that separated
Hello List,
Is there any reason why Postgres should not support an ALTER TABLE
tablename [IF EXISTS] feature? (And similar for other ALTER
OBJECTTYPE)
For example, a hypothetical statement that attempts to drop a
constraint in a *completely* optional manner would look like the
following:
2010/11/5 Pavel Stehule pavel.steh...@gmail.com:
Hello
I am looking on http://kputnam.github.com/piggly/ site. I am thinking,
so can be very easy write low level support to plpgsql. And this can
to solve a some issue of plpgsql with lazy SQL full checking.
A raising syntax error of some SQL
Alvaro Herrera alvhe...@commandprompt.com writes:
The has_privs_of_role() call has the wrong ACL_KIND argument in the
error report.
Ah yes, I missed the acl_kind. It's a parameter of the function in the
v7 patch, attached.
(Nitpick: don't use e.g. at the end of the phrase. It seems strange
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, seeing the amount of new includes in extension.c, I wonder if it'd
be better to move AlterExtensionNamespace to alter.c.
It was mainly missing includes cleanup. The guts of the function is now
so short I can inline it in this mail:
On Fri, 5 Nov 2010 16:27:49 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Fri, Nov 5, 2010 at 4:00 PM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
* am_beginscan() - first call of FdwRoutine.Iterate()?
It might be good to have a separated beginscan method if we use
Shigeru HANADA han...@metrosystems.co.jp writes:
Thanks, now I see your point. Current FdwRoutine has no appropriate
function because Open is called from ExecutorStart which is used by
EXPLAIN too.
But then we have mismatch between executor node interface and FDW
interface about BeginScan.
Daniel Farina drfar...@acm.org writes:
Is there any reason why Postgres should not support an ALTER TABLE
tablename [IF EXISTS] feature?
I think you've phrased the question backwards. Why *should* we support
that large increment of complexity? The use-cases seem pretty few and
far between.
On Nov 5, 2010, at 10:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
Is there any reason why Postgres should not support an ALTER TABLE
tablename [IF EXISTS] feature?
I think you've phrased the question backwards. Why *should* we support
that large
Robert Haas robertmh...@gmail.com writes:
On Nov 5, 2010, at 10:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think you've phrased the question backwards. Why *should* we support
that large increment of complexity? The use-cases seem pretty few and
far between.
Obviously we have different
Hello Alexander,
Here follows a review of your patch.
Hackers,
Seg contrib module contains the same bug in picksplit function as
cube contrib module.
Good catch! :-)
Also, Guttman's split algorithm is not needed in unidimensional case,
because sorting based algorithm is good in this case.
Excerpts from Dimitri Fontaine's message of vie nov 05 06:49:34 -0300 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, seeing the amount of new includes in extension.c, I wonder if it'd
be better to move AlterExtensionNamespace to alter.c.
It was mainly missing includes
Excerpts from Jan Urbański's message of vie nov 05 04:19:07 -0300 2010:
PS: I'm wondering if there's any noticable slowdown from always starting
a subxact before doing SPI. Plperl users seemed not to notice, so I
guess I shouldn't worry.
I think it's more plperl users have to put up with it
Hello Yeb,
Thank you for review and code refactoring.
PS: when comparing with gbt_num_picksplit, I noticed that that one does not
update v-spl_ldatum and spl_rdatum to the union datums, but initializes
these to 0 at the beginning and never seems to update them. Not sure if this
is a problem
Alvaro Herrera alvhe...@commandprompt.com writes:
Frankly, the get_extension_namespace bit still feels wrong to me. I
would have the namespace be present in the pg_extension catalog, even if
it's not part of the primary key. This would let you answer the
question: what schema did I install
On Fri, Nov 5, 2010 at 8:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That spells large maintenance burden to me, even if any one command
would be relatively simple to fix. And we haven't even reached the
question of whether pg_dump could use these things usefully; I suspect
that the bottom-line
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Alvaro Herrera alvhe...@commandprompt.com writes:
Frankly, the get_extension_namespace bit still feels wrong to me. I
would have the namespace be present in the pg_extension catalog, even if
it's not part of the primary key.
Well, I'm thinking
Daniel Farina drfar...@acm.org writes:
Well, why not? I was in the middle of writing it. But I'm open to
other approaches, the real motivating issue could be stated simply as:
pg_dump --clean should produce output that can be run on empty, full
or partially-full databases in a transaction
Tom Lane t...@sss.pgh.pa.us writes:
I'm with Alvaro on this. If we're going to have an ALTER EXTENSION SET
SCHEMA operation, then extensions must have a well-defined schema
property, and it would be good if that connection were explicitly
represented in the catalogs. Digging stuff out of
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
BTW, I'm not even 100% convinced that the schema shouldn't be part of
the extension's name, if we're going to make it work like this. Is
there a reason I shouldn't be able to have both public.myextension
and
Hi list,
PostgreSQL's default settings change when built with Linux kernel
headers 2.6.33 or newer. As discussed on the pgsql-performance list,
this causes a significant performance regression:
http://archives.postgresql.org/pgsql-performance/2010-10/msg00602.php
NB! I am not proposing to change
On Fri, Nov 5, 2010 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What you're proposing would maybe be useful for overwriting a database
that contains portions of what is in the source database, but what's
the use of that? You could just as well dropdb and start fresh. The
interesting case
Daniel Farina drfar...@acm.org writes:
I am somewhat sympathetic to this argument, except for one thing:
pg_dump --clean will successfully and silently wipe out a foreign key
right now, should it exist,
No, it will not, because we don't use CASCADE in the drop commands.
The case I'm thinking
Marti Raudsepp ma...@juffo.org writes:
PostgreSQL's default settings change when built with Linux kernel
headers 2.6.33 or newer. As discussed on the pgsql-performance list,
this causes a significant performance regression:
http://archives.postgresql.org/pgsql-performance/2010-10/msg00602.php
Tom Lane t...@sss.pgh.pa.us writes:
Are you proposing that an extension object is schema qualified?
Dunno, I'm just asking the question. If it isn't, why not?
Because extension are much like languages for stored procedure, on the
utility side rather than on the query side. The only queries
Folks,
I'm continuing in my efforts now to document how to deploy and manage
replication on our wiki. One of the things a DBA needs to do is to use
pg_current_xlog_location() (and related functions) to check how far
behind the master the standby is.
However, there's some serious problems with
On Fri, Nov 5, 2010 at 20:13, Tom Lane t...@sss.pgh.pa.us wrote:
I'm less than convinced this is the right approach ...
If open_dsync is so bad for performance on Linux, maybe it's bad
everywhere? Should we be rethinking the default preference order?
Sure, maybe for PostgreSQL 9.1
But the
Marti Raudsepp ma...@juffo.org writes:
On Fri, Nov 5, 2010 at 20:13, Tom Lane t...@sss.pgh.pa.us wrote:
If open_dsync is so bad for performance on Linux, maybe it's bad
everywhere? Â Should we be rethinking the default preference order?
So I think we should aim to fix old versions first. Do
On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
I am somewhat sympathetic to this argument, except for one thing:
pg_dump --clean will successfully and silently wipe out a foreign key
right now, should it exist,
No, it will not,
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Here's another question: if an extension's objects live (mostly or
entirely) in schema X, what happens if the possibly-unprivileged owner
of schema X decides to drop it? If the extension itself is considered
Hi,
A customer of ours has the need for temporary functions. The use case
is writing test cases for their databases: the idea being that their
code creates a temp function which then goes away automatically at
session end, just like a temp table. It's said that this makes things
generally
On 5 November 2010 20:36, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
Hi,
A customer of ours has the need for temporary functions. The use case
is writing test cases for their databases: the idea being that their
code creates a temp function which then goes away automatically at
session
On Nov 5, 2010, at 12:36 PM, Alvaro Herrera wrote:
Hi,
A customer of ours has the need for temporary functions. The use case
is writing test cases for their databases: the idea being that their
code creates a temp function which then goes away automatically at
session end, just like a
Tom Lane t...@sss.pgh.pa.us writes:
You're mistaken, and this case definitely does need more thought.
A schema owner is presumed to have the unconditional right to
drop anything in his schema, whether he owns it or not.
Here a paste of how it works with current code.
dim=# create schema bob
On Fri, Nov 5, 2010 at 21:20, Tom Lane t...@sss.pgh.pa.us wrote:
Marti Raudsepp ma...@juffo.org writes:
On Fri, Nov 5, 2010 at 20:13, Tom Lane t...@sss.pgh.pa.us wrote:
If open_dsync is so bad for performance on Linux, maybe it's bad
everywhere? Should we be rethinking the default preference
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
A customer of ours has the need for temporary functions.
You can do that now:
regression=# create function pg_temp.foo(f1 int) returns int
regression-# as 'select $1+1' language sql;
CREATE FUNCTION
regression=# select pg_temp.foo(1);
foo
-
Excerpts from Dimitri Fontaine's message of vie nov 05 16:58:00 -0300 2010:
dim= drop schema bob cascade;
NOTICE: drop cascades to extension unaccent
DROP SCHEMA
dim= \c - dim
You are now connected to database dim as user dim.
dim=# select installed from pg_extensions where name =
Alvaro Herrera alvhe...@commandprompt.com writes:
Basically you're saying that the owner of the schema in which the
extension is installed can drop the extension ... even though, according
to your previous argument, the extension is not in said schema :-)
Yeah it's a case of defining things.
Marti Raudsepp ma...@juffo.org writes:
On Fri, Nov 5, 2010 at 21:20, Tom Lane t...@sss.pgh.pa.us wrote:
What's that got to do with it?
I'm not sure what you're asking.
Surely changing the default wal_sync_method for all OSes in
maintenance releases is out of the question, no?
Well, if we
Fellow Hackers,
I'm writing a function to turn an EXPLAIN plan into a table with columns. As
such, I need to have a complete list of the various bits of each plan node and
their types for the table. Here's what I've got so far:
Node Type TEXT,
StrategyTEXT,
Daniel Farina drfar...@acm.org writes:
On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
pg_dump --clean will successfully and silently wipe out a foreign key
right now, should it exist,
No, it will not, because we don't use CASCADE
On 11/05/2010 04:27 PM, David E. Wheeler wrote:
Fellow Hackers,
I'm writing a function to turn an EXPLAIN plan into a table with columns. As
such, I need to have a complete list of the various bits of each plan node and
their types for the table. Here's what I've got so far:
Node Type
David E. Wheeler da...@kineticode.com writes:
* Is there some place in the source with a canonical list?
It seems that you need to read through ExplainNode in
src/backend/commands/explain.c:
Of course, there are containers too, which are not in your list at all.
How do you intend to represent the tree-ish structure in a flat table?
Andrew: we'll use a proximity tree.
--
-- Josh Berkus
PostgreSQL Experts Inc.
On Nov 5, 2010, at 1:36 PM, Andrew Dunstan wrote:
Of course, there are containers too, which are not in your list at all. How
do you intend to represent the tree-ish structure in a flat table?
So far I see only two containers: Subplans and Sot Keys. The latter is
represented as an array. The
On Nov 5, 2010, at 1:38 PM, Dimitri Fontaine wrote:
It seems that you need to read through ExplainNode in
src/backend/commands/explain.c:
http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/backend/commands/explain.c;h=f494ec98e510c23120e072bd5ee8821ea12738a4;hb=HEAD#l617
Ah,
On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
pg_dump --clean will successfully and silently wipe out a foreign key
right now,
On Nov 5, 2010, at 1:42 PM, David E. Wheeler wrote:
On Nov 5, 2010, at 1:38 PM, Dimitri Fontaine wrote:
It seems that you need to read through ExplainNode in
src/backend/commands/explain.c:
960 ExplainPropertyFloat(Plan Rows, plan-plan_rows, 0, es);
Should rows really be a float?
Yeah, since PropertyInteger is 32-bit.
--
-- Josh Berkus
PostgreSQL Experts Inc.
On Friday 05 November 2010 19:13:47 Tom Lane wrote:
Marti Raudsepp ma...@juffo.org writes:
PostgreSQL's default settings change when built with Linux kernel
headers 2.6.33 or newer. As discussed on the pgsql-performance list,
this causes a significant performance regression:
On Fri, Nov 5, 2010 at 22:16, Tom Lane t...@sss.pgh.pa.us wrote:
I don't really think that change the default on Linux is that
much nicer than change the default everywhere when it comes to
what we ought to consider back-patching. In any case, you're getting
ahead of the game: we need to
Some time ago, CREATE CONSTRAINT TRIGGER was a deprecated command and it
was slated for obsolence or removal.
Recent developments have turned it back into non-deprecated mode; it's
not going anywhere, and it needs to be fully documented.
It seems to me that it makes more sense to merge its
I wondered why some of the buildfarm machines were showing
max_stack_depth = 100kB, and Andrew Dunstan kindly lent me the
use of dungbeetle to check it out. What I found out:
1. max_stack_depth has the expected value (equal to ulimit -s)
in any manually started postmaster. It only drops to
Tom Lane wrote:
If open_dsync is so bad for performance on Linux, maybe it's bad
everywhere? Should we be rethinking the default preference order?
And I've seen the expected sync write performance gain over fdatasync on
a system with a battery-backed cache running VxFS on Linux, because
On Fri, Nov 5, 2010 at 2:37 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
Recent developments have turned it back into non-deprecated mode; it's
not going anywhere, and it needs to be fully documented.
From what I recall, there isn't anything in the trigger documentation
or CREATE
Josh Berkus j...@agliodbs.com writes:
960 ExplainPropertyFloat(Plan Rows, plan-plan_rows, 0, es);
Should rows really be a float?
Yeah, since PropertyInteger is 32-bit.
Yes, plan_rows is a float. We might need to represent very large
values, and we do not need high accuracy, so
Andres Freund and...@anarazel.de writes:
On Friday 05 November 2010 19:13:47 Tom Lane wrote:
If open_dsync is so bad for performance on Linux, maybe it's bad
everywhere? Should we be rethinking the default preference order?
I fail to see how it could be beneficial on *any* non-buggy
On Friday 05 November 2010 22:53:37 Greg Smith wrote:
If open_dsync is so bad for performance on Linux, maybe it's bad
everywhere? Should we be rethinking the default preference order?
And I've seen the expected sync write performance gain over fdatasync on
a system with a
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Some time ago, CREATE CONSTRAINT TRIGGER was a deprecated command and it
was slated for obsolence or removal.
Recent developments have turned it back into non-deprecated mode; it's
not going anywhere, and it needs to be fully documented.
It
On 11/05/2010 05:45 PM, Tom Lane wrote:
Anyway, what this points up is that we are making a very conservative
assumption about what to do when getrlimit() returns RLIM_INFINITY.
It does not seem real reasonable to interpret that as 100kB on any
modern platform. I'm inclined to interpret it
I think the original idea was that if you had a dedicated WAL drive then
sync-on-write would be reasonable. But that was a very long time ago
and I'm not sure that the system's behavior is anything like what it was
then; for that matter I'm not sure we had proof that it was an optimal
Josh Berkus j...@agliodbs.com writes:
What plaforms do we need to test to get a reasonable idea? Solaris,
FreeBSD, Windows?
At least. I'm hoping that Greg Smith will take the lead on testing
this, since he seems to have spent the most time in the area so far.
regards,
On 11/5/10 3:31 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
What plaforms do we need to test to get a reasonable idea? Solaris,
FreeBSD, Windows?
At least. I'm hoping that Greg Smith will take the lead on testing
this, since he seems to have spent the most time in the area so
On Tue, 2010-10-19 at 10:31 +0200, Dimitri Fontaine wrote:
4. I can start a new replica off the master by running a single command-line
utility on the standby and giving it connection information to the master.
Using this connection, it should be able to start a backup snapshot, copy
the
Andrew Dunstan and...@dunslane.net writes:
On 11/05/2010 05:45 PM, Tom Lane wrote:
Anyway, what this points up is that we are making a very conservative
assumption about what to do when getrlimit() returns RLIM_INFINITY.
It does not seem real reasonable to interpret that as 100kB on any
(Prompted by a puzzled user on IRC)
Ten years ago, nearly, we made this commit
https://github.com/postgres/postgres/commit/8a2cdd77ad5c0a4f8902ea86d0377336e076abcb
(see what a good thing it is we carefully got all the history
transferred to git?)
The comment on the commit says:
EXECUTE
Andrew Dunstan and...@dunslane.net writes:
The comment on the commit says:
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error,
rather than executing the INTO clause with non-plpgsql semantics
as it was doing for the last few weeks/months. This keeps our options
On 11/05/2010 06:54 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
The comment on the commit says:
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error,
rather than executing the INTO clause with non-plpgsql semantics
as it was doing for the last few
On Fri, Nov 5, 2010 at 4:48 PM, Daniel Farina drfar...@acm.org wrote:
On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
pg_dump
On Fri, Nov 5, 2010 at 4:20 PM, Robert Haas robertmh...@gmail.com wrote:
Can you give us a self-contained example of the problem you're talking about?
Sure. Consider the following:
CREATE TABLE t1 (
id integer PRIMARY KEY
);
CREATE TABLE t2 (
id integer PRIMARY KEY,
fk integer
);
On Fri, Nov 5, 2010 at 2:46 PM, Josh Berkus j...@agliodbs.com wrote:
I'm continuing in my efforts now to document how to deploy and manage
replication on our wiki. One of the things a DBA needs to do is to use
pg_current_xlog_location() (and related functions) to check how far
behind the
On Thu, Nov 4, 2010 at 9:00 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Nov 4, 2010 at 10:27 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Nov 2, 2010 at 10:38 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Fujii Masao masao.fu...@gmail.com writes:
After 9.0 release, I've
On Fri, Nov 5, 2010 at 4:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
A customer of ours has the need for temporary functions.
You can do that now:
regression=# create function pg_temp.foo(f1 int) returns int
regression-# as 'select $1+1' language
On Fri, Nov 5, 2010 at 5:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Nov 5, 2010 at 2:46 PM, Josh Berkus j...@agliodbs.com wrote:
I'm continuing in my efforts now to document how to deploy and manage
replication on our wiki. One of the things a DBA needs to do is to use
77 matches
Mail list logo
