Tom Lane [EMAIL PROTECTED] writes:
Partition Elimination relies upon being able to prove at execution time
You mean plan time.
Fwiw, both are possible.
In oracle there are (at least) three different cases:
1. For queries like select * from tab the plan shows a multiple partition
scan.
2.
Tom Lane [EMAIL PROTECTED] writes:
UPDATE totals SET
xmax = ss.xmax, xmin = ss.xmin, ...
FROM
(SELECT groupid, max(x) AS xmax, ... FROM details GROUP BY groupid) ss
WHERE groupid = ss.groupid;
...
Of course this syntax isn't standard either ... but we already
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 12:32 AM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Another way to help in this particular case would be to
have libpq on
win32 only force-lowercase the username IF it was retreived
from the
system (but not when manually specified).
Well, I personally don't care how bizarrely the Win32 port
behaves ;-) so I won't complain if
Bruce Momjian wrote:
Josh Berkus wrote:
I think that private variables and private functions need to be part of the
definition.
OK, so it seems we need:
C static/private functions for schemas
C static/private variables for schemas
Are private variables implemented via the
-- Forwarded message --
From: Adrian Maier [EMAIL PROTECTED]
Date: May 10, 2005 12:01 PM
Subject: Re: [HACKERS] Oracle Style packages on postgres
To: Jim C. Nasby [EMAIL PROTECTED]
On 5/9/05, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Sun, May 08, 2005 at 10:38:41PM -0500, Bob
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 5:45 PM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 12:32 AM
To: John Hansen
Cc:
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
UPDATE totals SET
xmax = ss.xmax, xmin = ss.xmin, ...
FROM
(SELECT groupid, max(x) AS xmax, ... FROM details GROUP BY groupid) ss
WHERE groupid = ss.groupid;
...
Of course this syntax isn't
On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
A more in-depth consideration of the major design options and trade-offs
available to us... this is an internals related discussion.
Comments?
1. Embellish inheritance or separate infrastructure?
Inheritance is a somewhat strange
Thomas Hallgren wrote:
Bruce Momjian wrote:
Josh Berkus wrote:
I think that private variables and private functions need to be part of the
definition.
OK, so it seems we need:
C static/private functions for schemas
C static/private variables for schemas
Are
On T, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
There are 2 possibly expensive steps:
1. the conversion to AND'ed list of simple clauses (unknown
complexity)
2. matching each of simple clauses in the and list with all others
Magnus Hagander [EMAIL PROTECTED] writes:
Which brings me back to thinking a GUC is the way to deal with that -
you'll definitly know what kind of KDC you have when you set up
Kerberos. But perhaps this GUC should be for permit case-insensitive
kerberos principals and not case-insensitive
-Original Message-
From: Mark Cave-Ayland [mailto:[EMAIL PROTECTED]
Sent: 07 March 2005 11:04
To: '[EMAIL PROTECTED]'
Cc: 'pgsql-hackers@postgreSQL.org'
Subject: Re: Cost of XLogInsert CRC calculations
(cut)
I suppose that the bulk of the CPU cycles being attributed to
Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I was just researching some articles on compression (zlib) and I saw mention
of the Adler-32 algorithm which is supposed to be slightly less accurate
than an equivalent CRC calculation but significantly faster to compute. I
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I was just researching some articles on compression (zlib) and I saw mention
of the Adler-32 algorithm which is supposed to be slightly less accurate
than an equivalent CRC calculation but significantly faster to compute. I
haven't located a good
Bruce Momjian wrote:
Thomas Hallgren wrote:
Bruce Momjian wrote:
Josh Berkus wrote:
I think that private variables and private functions need to be part of the
definition.
OK, so it seems we need:
C static/private functions for schemas
C static/private
Bruce Momjian schrieb:
OK, so it seems we need:
C static/private functions for schemas
C static/private variables for schemas
Are private variables implemented via the temporary per-session schema?
nested schemas
What does the standard say?
Is that it?
Yeah,
that would
Hai,
I need a clarification for the below:
I need to check for the existence of a user defined view named 'audit_vw'
and if exists, then i need to delete the same. Please help me to solve the
issue.
Thanks Regards
Palanivel P.K
Important Email Information :- The information in this
Am Montag, 9. Mai 2005 00:41 schrieb Andrew - Supernews:
c) In most places, system objects are segregated from
user objects, e.g. pg_user_indexes
I think that is a bad idea as it goes against the fundamental design of
PostgreSQL.
In what way? Please elaborate.
PostgreSQL does not
Am Freitag, 6. Mai 2005 12:20 schrieb Andreas Pflug:
and the information_schema is next to useless for these things since
it doesn't have PostgreSQL specific things in it.
And the restriction to current user owned objects reduces usability to
zero.
The information schema restricts the
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 8:43 AM
To: Thomas Hallgren
Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Oracle Style packages on postgres
[...]
I suppose. I think we should
Am Freitag, 6. Mai 2005 12:20 schrieb Andreas Pflug:
and the information_schema is next to useless for these things
since
it doesn't have PostgreSQL specific things in it.
And the restriction to current user owned objects reduces usability
to
zero.
The information schema restricts
Which brings me back to thinking a GUC is the way to deal
with that -
you'll definitly know what kind of KDC you have when you set up
Kerberos. But perhaps this GUC should be for permit
case-insensitive
kerberos principals and not case-insensitive usernames. And it
would just
Try selecting from pg_views to see if it exists, then if it does, drop it.
Chris
[EMAIL PROTECTED] wrote:
Hai,
I need a clarification for the below:
I need to check for the existence of a user defined view named 'audit_vw'
and if exists, then i need to delete the same. Please help me to solve the
It would seem that the planner does not take into account whether the
datatypes involved have the capability to use hash aggregates or not.
sdb=# explain select query_start, current_query from pg_locks join
stat_activity on pid = procpid where granted = true and transaction in (select
Rod Taylor [EMAIL PROTECTED] writes:
It would seem that the planner does not take into account whether the
datatypes involved have the capability to use hash aggregates or not.
sdb=# explain select query_start, current_query from pg_locks join
stat_activity on pid = procpid where
Hi ppl,
I'm currently building some stored procedures in C that uses some internal
hash tables - It could be really nice to be able to deallocate those
correctly when e.g. a memctx is destroyed. Would it be possible to add this
as a postgresql feature and how should it be done.
I also have
On Tue, 2005-05-10 at 12:11 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
It would seem that the planner does not take into account whether the
datatypes involved have the capability to use hash aggregates or not.
sdb=# explain select query_start, current_query from
Rod Taylor [EMAIL PROTECTED] writes:
Oh, stat_activity is a view which removes idle connections from
displaying and allows non-privileged users to see everything that's
going on within the DB.
Still works fine for me. Do you even have an operator 716373?
If so what is it?
Peter, Merlin, Andrew,
And the restriction to current user owned objects reduces usability
to
zero.
The information schema restricts the views to the objects to which you
have
some access right, which doesn't seem all that useless.
There's a difference between restricting it to
On Tue, 2005-05-10 at 12:50 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Oh, stat_activity is a view which removes idle connections from
displaying and allows non-privileged users to see everything that's
going on within the DB.
Still works fine for me. Do you even have
Rod Taylor [EMAIL PROTECTED] writes:
It's the = operator that Slony adds for xxid comparisons. I didn't even
think of changes Slony would have made.
ssdb=# select * from pg_operator where oid = 716373;
oprname | oprnamespace | oprowner | oprkind | oprcanhash | oprleft |
oprright |
Folks,
We've meandered a bit on this, so I wanted to summarize the arguments
presented on the new system views to date so that we might have some hope of
consensus before feature freeze.
As I see it, there are 3 main arguments about having the new system views at
all. These obviously need
... thus, as I see it, the *primary* question is in fact argument (2). That
is, is information_schema sufficient, and if not, can it be extended without
breaking SQL standards? Argument (1) did not seem to have a lot of evidence
on the con side, and the strongest argument against (3) is that
On Tue, May 10, 2005 at 04:55:40PM +0200, Peter Eisentraut wrote:
Am Montag, 9. Mai 2005 00:41 schrieb Andrew - Supernews:
c) In most places, system objects are segregated from
user objects, e.g. pg_user_indexes
I think that is a bad idea as it goes against the fundamental design of
Suggestion:
Use INFORMATION_SCHEMA for everything that INFORMATION_SCHEMA covers.
That way, there will not be needless duplications.
Create new tables with foreign keys to the INFORMATION_SCHEMA for
everything else.
Alternative suggestion:
Create any sort of magic, pg-specific schema you want,
On Tue, May 10, 2005 at 12:01:54PM +0300, Adrian Maier wrote:
Personally, I think the biggest win here would be adding package support
and syntax to plpgsql. Not only would it make porting from Oracle
easier, it would also make plpgsql much, much more powerful.
Hello,
What do you think
On Mon, May 09, 2005 at 11:24:45PM +0200, Thomas Hallgren wrote:
In Oracle you can use the syntax:
schema.package.function()
but you can just as well use the syntax:
schema.type.static method()
Why do you need both? If PostgreSQL is going to add new nice features
that enables better
On 2005-05-10, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Freitag, 6. Mai 2005 12:20 schrieb Andreas Pflug:
and the information_schema is next to useless for these things since
it doesn't have PostgreSQL specific things in it.
And the restriction to current user owned objects reduces
On Mon, May 09, 2005 at 09:56:53PM -0400, Bruce Momjian wrote:
OK, so it seems we need:
C static/private functions for schemas
C static/private variables for schemas
Are private variables implemented via the temporary per-session schema?
nested schemas
What does the
On Tue, 10 May 2005 [EMAIL PROTECTED] wrote:
I need to check for the existence of a user defined view named 'audit_vw'
and if exists, then i need to delete the same. Please help me to solve the
issue.
If you don't need to do anything else in the transaction, you could just
issue DROP VIEW
my bad [thanks Greg]
Peter, Merlin, Andrew,
And the restriction to current user owned objects reduces
usability
to
zero.
The information schema restricts the views to the objects to which
you
have
some access right, which doesn't seem all that useless.
There's a
On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
1. Embellish inheritance or separate infrastructure?
It seems prudent to avoid building on that foundation, even though we
may decide
On Tue, May 10, 2005 at 10:21:06AM -0700, Josh Berkus wrote:
Folks,
We've meandered a bit on this, so I wanted to summarize the
arguments presented on the new system views to date so that we might
have some hope of consensus before feature freeze.
As I see it, there are 3 main
Jim C. Nasby wrote:
I don't believe types allow for internal-only methods. I seem to recall
other limitations on what types could do as opposed to packages. Of
course, we need not restrict ourselves in such a manner.
Do Oracle packages support internal only functions? If they do, then I
agree,
On Tue, May 10, 2005 at 08:40:16PM +0200, Thomas Hallgren wrote:
Jim C. Nasby wrote:
I don't believe types allow for internal-only methods. I seem to recall
other limitations on what types could do as opposed to packages. Of
course, we need not restrict ourselves in such a manner.
Do
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
I disagree. The code is there, it could use work, and what you are
basically proposing is to duplicate both the existing work and much
of the
Jim C. Nasby wrote:
I guess maybe I'm not clear on what you mean by static methods. IIRC, in
Oracle nomenclature, static means it will retain state between
invocations in the same session. Of course, functions and procedures
that don't do this are also allowed.
A STATIC prefix on a method
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 10, 2005 at 04:55:40PM +0200, Peter Eisentraut wrote:
PostgreSQL does not really distinguish between system and user things.
How will you do that?
It's currently done using this function:
create or replace function
Dave Held wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 8:43 AM
To: Thomas Hallgren
Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Oracle Style packages on postgres
[...]
I
Tom,
I think the real problem here is that it's hard to be all things to all
people. If you suppress display of certain objects, that may be nice
suppression of clutter for one user, yet render the view useless from
the perspective of another user --- or even the same user on a different
That depends; is the SFLC offering to pay for the patent applications? Last
I
checked, it was somewhere around $6000 per patent.
Nolo press (www.nolo.com) sells a book on patents. Many people file their own
patent applications successfully. The cost is less that $1000.
David
On Sun, 8 May 2005, Tom Lane wrote:
While your original patch is buggy, it's at least fixable and has
localized, limited impact. I don't think these schemes are safe
at all --- they put a great deal more weight on the semantics of
the filesystem than I care to do.
I'm going to try this some more,
Heikki Linnakangas wrote:
On Sun, 8 May 2005, Tom Lane wrote:
While your original patch is buggy, it's at least fixable and has
localized, limited impact. I don't think these schemes are safe
at all --- they put a great deal more weight on the semantics of
the filesystem than I care to
I've talked to a friend of mine who is a patent lawyer.
1) in Europe if it is in the public domain then it cannot be patented
2) in North America you would have to patent before submitting to the
project.
3) His question was why? With a bsd license you can't stop anyone from
using it and nobody
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Sun, 8 May 2005, Tom Lane wrote:
While your original patch is buggy, it's at least fixable and has
localized, limited impact. I don't think these schemes are safe
at all --- they put a great deal more weight on the semantics of
the filesystem
On Tue, 10 May 2005, Bruce Momjian wrote:
The current code is nice and localized and doesn't add any burden on our
existing code, which is already complicated enough. I think we either
fix checkfiles.c, or we remove it and decide it isn't worth checking for
unrefrenced files.
Let's pull the patch
On Tue, 2005-05-10 at 10:34 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I was just researching some articles on compression (zlib) and I saw
mention
of the Adler-32 algorithm which is supposed to be slightly less accurate
than an
On Tue, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
ISTM fairly straightforward to produce a similar static plan along the
same lines, using Result nodes to implement Partition Elimination.
Append
Result
SeqScan
Result
On Tue, 2005-05-10 at 16:44 +0300, Hannu Krosing wrote:
On T, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
There are 2 possibly expensive steps:
1. the conversion to AND'ed list of simple clauses (unknown
complexity)
2.
Simon Riggs [EMAIL PROTECTED] writes:
The cause of the performance problem has been attributed to it being a
64-bit rather than 32-bit calculation. That is certainly part of it, but
I have seen evidence that there is an Intel processor stall associated
with the use of a single byte constant
Heikki Linnakangas wrote:
On Tue, 10 May 2005, Bruce Momjian wrote:
The current code is nice and localized and doesn't add any burden on our
existing code, which is already complicated enough. I think we either
fix checkfiles.c, or we remove it and decide it isn't worth checking for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
interface designers who are designing for 3rd-party multi-database
products who are not supporting PostgreSQL yet and will be
unlikely to learn the system tables
There's a scary thought.
So they are willing to learn the new system views, but
On Tue, 2005-05-10 at 15:01 -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
I disagree. The code is there, it could use work, and what you are
basically proposing
OK, so it seems we need:
o make private objects accessable only to objects
in the same schema
o Allow current_schema.objname to access current
schema objects
o session variables
o nested schemas?
On Tue, 2005-05-10 at 18:22 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The cause of the performance problem has been attributed to it being a
64-bit rather than 32-bit calculation. That is certainly part of it, but
I have seen evidence that there is an Intel processor
Bruce Momjian wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes, pg_relnamespace is definitely not null. I've actually already removed
the left
On May 11, 2005, at 7:38, Greg Sabino Mullane wrote:
So they are willing to learn the new system views, but not the system
tables? The above seems an argument for I_S, or at least an expanded
I_S.
So... the reason we don't want to expand (not alter) I_S is that it is
a
standard that very few
On Tue, 10 May 2005, Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes, pg_relnamespace is definitely not null. I've actually
Hi!
Need a piece of advice here. I'm wrapping up the ports for FreeBSD, and jus
wonder if it is perhaps clever to always add --enable-thread-safety to the
configure args. Is there a big enough penalty for having it off by default,
or can I just have it on always?
/Palle
On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
OK, so it seems we need:
o make private objects accessable only to objects
in the same schema
o Allow current_schema.objname to access current
schema objects
o session variables
Marc G. Fournier wrote:
On Tue, 10 May 2005, Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes,
David Fetter wrote:
On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
OK, so it seems we need:
o make private objects accessable only to objects
in the same schema
o Allow current_schema.objname to access current
schema objects
o
Palle Girgensohn wrote:
Hi!
Need a piece of advice here. I'm wrapping up the ports for FreeBSD, and jus
wonder if it is perhaps clever to always add --enable-thread-safety to the
configure args. Is there a big enough penalty for having it off by default,
or can I just have it on always?
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Tue, 10 May 2005, Bruce Momjian wrote:
The current code is nice and localized and doesn't add any burden on our
existing code, which is already complicated enough. I think we either
fix checkfiles.c, or we remove it and decide it isn't worth
On Tue, May 10, 2005 at 16:57:01 -0400,
Dave Cramer [EMAIL PROTECTED] wrote:
3) His question was why? With a bsd license you can't stop anyone from
using it and nobody
else can patent it since by placing it in the project you are
establishing prior art.
Nope. They can still be issued a
On Tue, May 10, 2005 at 09:49:13PM -0400, Bruce Momjian wrote:
David Fetter wrote:
On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
OK, so it seems we need:
o make private objects accessable only to objects in the same
schema
o Allow
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, so it seems we need:
o make private objects accessable only to objects
in the same schema
o Allow current_schema.objname to access current
schema objects
o session variables
o nested schemas?
Bruce Momjian pgman@candle.pha.pa.us writes:
Palle Girgensohn wrote:
Need a piece of advice here. I'm wrapping up the ports for FreeBSD, and jus
wonder if it is perhaps clever to always add --enable-thread-safety to the
configure args. Is there a big enough penalty for having it off by
79 matches
Mail list logo
