David E. Wheeler wrote:
Howdy Hackers,
Is there a published maintenance policy somewhere? Something that says
for how long the project supports minor releases of PostgreSQL.
We don't have a published policy, but I believe an unofficial policy has
been to support minor releases for about 5
On Tue, Jul 7, 2009 at 8:28 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
For
example, does 7.4 still get bug fixes and minor releases? If not, how
does one know when support for a major version has been dropped?
Hmm, I thought we dropped support for 7.4 a while ago, and
David E. Wheeler wrote:
This code:
CREATE OR REPLACE FUNCTION foo() returns boolean as $$
DECLARE
have_rec record;
want_rec record;
BEGIN
have_rec := row(1, 2);
want_rec := row(3, 5);
RETURN have_rec IS DISTINCT FROM want_rec;
On Sat, Jul 04, 2009 at 03:39:14PM +0200, Boszormenyi Zoltan wrote:
The attached patch is built upon our previous patch supporting
dynamic cursor and SQLDA.
Please don't do this unless the new patch relies on some changes made in the
older one.
Michael
--
Michael Meskes
Michael at Fam-Meskes
On Sat, Jul 04, 2009 at 05:09:04PM +0200, Boszormenyi Zoltan wrote:
OK, let me retry. This version treats string as a non-reserved word,
and also discovers whether the PGC contains this construct below,
as in ecpg/tests/preproc/type.pgc:
exec sql type string is char[11];
typedef char
Fujii Masao wrote:
On Tue, Jul 7, 2009 at 12:16 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
In order for the primary server (ie. a normal backend) to read an archived
file,
restore_command needs to be specified in also postgresql.conf. In this case,
how
Hi folks,
We're now about a week away from the start of the July 2009
commitfest, and we need to make a decision about whether to start
using http://commitfest.postgresql.org to manage it, or punt to the
next commitfest and continue to use the wiki for July.
Robert and I have been upgrading the
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
For pgcrypto functions, user's SQL must contain keyword strings
and they
Itagaki Takahiro wrote:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
For pgcrypto functions, user's SQL must
On Tue, Jul 7, 2009 at 10:09 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
What kind of attacks would this protect against? Seems a bit pointless
to me if the password is being sent to the server anyway. If the
attacker has superuser access to the server, he can harvest the
Yes. I am working to integrate some of the comments received for the patch.
I would be able to post latest patch in the next week.
Regards,
--
Kedar.
On Tue, Jul 7, 2009 at 10:18 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Jun 8, 2009 at 9:02 AM, Kedar
Greg Stark wrote:
On Tue, Jul 7, 2009 at 10:09 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
What kind of attacks would this protect against? Seems a bit pointless
to me if the password is being sent to the server anyway. If the
attacker has superuser access to the server,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 07, 2009 at 05:35:28PM +0900, Itagaki Takahiro wrote:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
As other posters have
On Monday 06 July 2009 23:00:18 Tom Lane wrote:
It seems to me that the right fix here is not so much to tweak the
message wording as to put in an error location cursor. In more
complicated cases (eg, multiple FOREIGN KEY clauses) the suggested
wording change wouldn't help much anyway.
It
On Fri, 2009-07-03 at 12:44 +0200, Petr Jelinek wrote:
Petr Jelinek wrote:
So, here is the first version of the patch.
Attached is v2 with slightly improved code, nothing has changed
feature-wise.
I would like to see
GRANT ... ON ALL OBJECTS ...
because I know that I will forget to do
Heikki Linnakangas wrote:
David E. Wheeler wrote:
Howdy Hackers,
Is there a published maintenance policy somewhere? Something that says
for how long the project supports minor releases of PostgreSQL.
We don't have a published policy, but I believe an unofficial policy has
been to
Heikki Linnakangas wrote:
While supporting multiple slaves
isn't a priority,
Really? I should have thought it was a basic requirement. At the very
least we need to design with it in mind.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
Thanks for the comment!
On Tue, Jul 7, 2009 at 5:07 PM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
pg_read_xlogfile() feels like a quite hacky way to implement that. Do we
require the master to always have read access to the PITR archive? And
indeed, to have a PITR
In response to Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
CREATE INDEX test_idx ON test USING gist
(i CONSTRAINT =, c CONSTRAINT );
which would avoid the need for updating the catalog, of course.
Hmm, looks like index-fied table's constrains
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Can you provide some more details about the objective of this patch? Or
a link to previous discussion?
Suppose, Greg's patch could be modified to support order OR index scans:
SELECT ... WHERE (c 10 AND c 20) OR (c 100 AND C 110) ORDER BY c DESC
with plan:
Result
- Append
-
Tom Lane writes:
Atsushi Ogawa a_og...@hi-ho.ne.jp writes:
Attached patch is reduce the memcpy calls from SearchCatCache
and SearchCatCacheList. This patch directly uses cache-cc_skey
in looking for hash table.
How much did you test this patch? I'm fairly sure it will break
things.
Robert Haas robertmh...@gmail.com wrote:
I'm interested in hearing from anyone who has practical experience
with tuning these variables, or any ideas on what we should test to
get a better idea as to how to set them.
I don't remember any clear resolution to the wild variations in plan
time
Peter Eisentraut pete...@gmx.net writes:
On Monday 06 July 2009 23:00:18 Tom Lane wrote:
It seems to me that the right fix here is not so much to tweak the
message wording as to put in an error location cursor. In more
complicated cases (eg, multiple FOREIGN KEY clauses) the suggested
Atsushi Ogawa a_og...@hi-ho.ne.jp writes:
Tom Lane writes:
There are cases where cache lookups happen recursively.
I tested regression test and pgbench. However, I did not consider
recursive case. I revised a patch for safe recursive call.
But I cannot find test case in which recursive call
Dave Page dp...@pgadmin.org writes:
On Tue, Jul 7, 2009 at 8:28 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, I thought we dropped support for 7.4 a while ago, and there's no
download link for it on www.postgresql.org anymore. But looking at the
CVS history, I see that
On Jul 7, 2009, at 9:31 AM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Robert Haas robertmh...@gmail.com wrote:
I'm interested in hearing from anyone who has practical experience
with tuning these variables, or any ideas on what we should test to
get a better idea as to how to set
Simon Riggs si...@2ndquadrant.com writes:
I would like to see
GRANT ... ON ALL OBJECTS ...
This seems inherently broken, since different types of objects
will have different grantable privileges.
(I'm sure we can do something intelligent with privileges that don't
apply to all object types
Hi Kevin, Hi all,
On Tuesday 07 July 2009 16:31:14 Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
I'm interested in hearing from anyone who has practical experience
with tuning these variables, or any ideas on what we should test to
get a better idea as to how to set them.
Andres Freund and...@anarazel.de writes:
I cannot reasonably plan some queries with join_collapse_limit set to 20. At
least not without setting the geqo limit very low and a geqo_effort to a low
value.
So I would definitely not agree that removing j_c_l is a good idea.
Can you show some
Fujii Masao masao.fu...@gmail.com writes:
On Tue, Jul 7, 2009 at 12:16 AM, Tom Lanet...@sss.pgh.pa.us wrote:
I confess to not having paid much attention to this thread so far, but ...
what is the rationale for having such a capability at all?
If the XLOG files which are required for recovery
Andrew Dunstan wrote:
I think we need to float a bug upstream to the perl guys on this, but
as a holding position I suggest that we alter the #ifdef test to avoid
calling PERL_SYS_INIT3() where MYMALLOC is defined. It's ugly, but I
can't think of another simple way around it (and we've
On Jul 7, 2009, at 12:49 AM, Albe Laurenz wrote:
Is this a known issue in 8.3? If so, is there a known workaround?
The change is probably here:
http://archives.postgresql.org/pgsql-committers/2008-10/msg00110.php
So I think it is safe to argue that this is not a bug in 8.3, but an
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to
desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large
set
of back branches, and a
On Tuesday 07 July 2009 17:40:50 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I cannot reasonably plan some queries with join_collapse_limit set to 20.
At least not without setting the geqo limit very low and a geqo_effort to
a low value.
So I would definitely not agree that
David E. Wheeler wrote:
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large set
of back
Brendan Jurd dire...@gmail.com wrote:
If you think the app is fundamentally less useful than the wiki,
please say so and we'll work out whether we can resolve your
objection in time for the start of the CF.
It's been down for a while now. I don't know if this is causal, but
the failure
Brendan Jurd dire...@gmail.com wrote:
If you think the app is fundamentally less useful than the wiki,
please say so and we'll work out whether we can resolve your
objection in time for the start of the CF.
Oh, sure -- I post about it being down, and seconds after I hit send
it comes up
2009/7/8 Kevin Grittner kevin.gritt...@wicourts.gov:
Oh, sure -- I post about it being down, and seconds after I hit send
it comes up again. :-/
Do we know that cause?
Well, no, since I've never observed it being down and I really have
no idea what you mean by that.
Maybe you could
Brendan Jurd dire...@gmail.com wrote:
Maybe you could describe the symptoms you observed? Was the
webserver totally uncontactable, or was it an error in the web app
itself?
When I clicked the link to edit the comment, it clocked until the
browser timed out. So then I tried the URL for
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I guess the question is whether there is anyone who has had a contrary
experience. (There must have been some benchmarks to justify adding
geqo at some point?)
The CVS history shows that geqo was integrated on 1997-02-19, which
I think means
On Tue, Jul 7, 2009 at 4:16 PM, Tom Lanet...@sss.pgh.pa.us wrote:
(I'm sure we can do something intelligent with privileges that don't
apply to all object types rather than just fail. e.g. UPDATE privilege
should be same as USAGE on a sequence.)
Anything you do in that line will be an ugly
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public
notice of any EOL for a branch. At least a couple of months,
preferably. If the lifetime were absolutely fixed it might not
matter so much, but as it isn't I think we owe that
Peter Eisentraut pete...@gmx.net writes:
On Sunday 10 May 2009 03:05:48 dam...@dalibo.info wrote:
Here's a second version. Main changes are :
* Child tables are sorted by name
* \d only shows the number of child tables
* \d+ shows the full list
Committed.
I looked at this patch. I'm a
David E. Wheeler wrote:
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public notice
of any EOL for a branch. At least a couple of months, preferably. If
the lifetime were absolutely fixed it might not matter so much, but as
it
On Tue, Jul 7, 2009 at 4:49 PM, Tom Lanet...@sss.pgh.pa.us wrote:
This design seems totally wrong to me. It's confusing the master's
pg_xlog directory with the archive. We should *not* use pg_xlog as
a long-term archive area; that's terrible from both a performance
and a reliability
Jeff Davis pg...@j-davis.com writes:
On Mon, 2009-07-06 at 18:27 +0100, Simon Riggs wrote:
In many cases, people add unique indexes solely to allow replication to
work correctly. The index itself may never be used, especially in high
volume applications.
Interesting. Maybe we should at least
Robert Haas robertmh...@gmail.com writes:
One possibility would be to remove join_collapse_limit entirely, but
that would eliminate one possibily-useful piece of functionality that
it current enables: namely, the ability to exactly specify the join
order by setting join_collapse_limit to 1.
On Tue, 2009-07-07 at 11:16 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
I would like to see
GRANT ... ON ALL OBJECTS ...
This seems inherently broken, since different types of objects
will have different grantable privileges.
(I'm sure we can do something
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
ALTER TABLE tab ADD CONSTRAINT UNIQUE (col1, col2) USING index
This would be very useful, though perhaps only because we do not have
REINDEX CONCURRENTLY.
It is likely to be useful in the future to allow an index with N
columns, yet which can
On Tue, Jul 7, 2009 at 5:58 PM, Tom Lanet...@sss.pgh.pa.us wrote:
So while I don't doubt that geqo was absolutely essential when it was
written, it's fair to question whether it still provides a real win.
And we could definitely stand to take another look at the default
thresholds
The whole
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Itagaki Takahiro wrote:
CREATE TYPE encrypted_text (
INPUT = pgp_sym_encrypt_text(textin($1), passward(), options()),
OUTPUT = textout(pgp_sym_decrypt_text($1, passward(), options())),
LIKE bytea
);
passward() and options()
Greg Stark gsst...@mit.edu writes:
We should benchmark the planner on increasingly large sets of
relations on a typical developer machine and set geqo to whatever
value the planner can handle in that length of time. I suspect even at
10s you're talking about substantially larger values than
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Mon, 2009-07-06 at 18:27 +0100, Simon Riggs wrote:
In many cases, people add unique indexes solely to allow replication to
work correctly. The index itself may never be used, especially in high
On Tuesday 07 July 2009 19:45:44 Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
We should benchmark the planner on increasingly large sets of
relations on a typical developer machine and set geqo to whatever
value the planner can handle in that length of time. I suspect even at
10s
On Tue, Jul 7, 2009 at 6:22 PM, Tom Lanet...@sss.pgh.pa.us wrote:
This seems a bit pointless. There is certainly not any use case for a
constraint without an enforcement mechanism (or at least none the PG
community is likely to consider legitimate ;-)). And it's not very
realistic to
Greg Stark gsst...@mit.edu writes:
On Tue, Jul 7, 2009 at 4:49 PM, Tom Lanet...@sss.pgh.pa.us wrote:
This design seems totally wrong to me.
...
But this conflicts with earlier discussions where we were concerned
about the length of the path wal has to travel between the master and
the
On Monday 06 July 2009 22:16:12 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I have the attached patch that would make character_octet_length the
product of character_octet_length and the maximum octet length of a
single character in the selected server encoding. So for UTF-8,
On Tue, 2009-07-07 at 18:36 +0100, Simon Riggs wrote:
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
It is likely to be useful in the future to allow an index with N
columns, yet which can provide uniqueness with N of those columns.
This capability is known as covered indexes and will be
On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
We have an RSS:
http://www.postgresql.org/versions.rss
Does anyone use it? And it only goes back to 8.0 and it served with
the text/html content-type.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-07-07 at 18:36 +0100, Simon Riggs wrote:
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
It is likely to be useful in the future to allow an index with N
columns, yet which can provide uniqueness with N of those columns.
This capability is
Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
On Tue, Jul 7, 2009 at 4:49 PM, Tom Lanet...@sss.pgh.pa.us wrote:
This design seems totally wrong to me.
...
But this conflicts with earlier discussions where we were concerned
about the length of the path wal has to travel between the
David E. Wheeler wrote:
On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
We have an RSS:
http://www.postgresql.org/versions.rss
Does anyone use it?
No idea.
And it only goes back to 8.0
Huh, true :-( This should be fixed.
and it served with the text/html content-type.
Not for me:
On Tuesday 07 July 2009 19:35:54 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Sunday 10 May 2009 03:05:48 dam...@dalibo.info wrote:
Here's a second version. Main changes are :
* Child tables are sorted by name
* \d only shows the number of child tables
* \d+ shows the
On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
And it only goes back to 8.0
Huh, true :-( This should be fixed.
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have formal
control over scheduled
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
And I'm sure people will want the option to retain WAL longer in the
master, to avoid an expensive resync if the slave falls behind. It would
be simple to provide a GUC option for always retain X GB of old WAL in
pg_xlog.
Right,
On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote:
We're now about a week away from the start of the July 2009
commitfest, and we need to make a decision about whether to start
using http://commitfest.postgresql.org to manage it, or punt to the
next commitfest and continue to use the wiki
David E. Wheeler wrote:
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public notice
of any EOL for a branch. At least a couple of months, preferably. If
the lifetime were absolutely fixed it might not matter so much, but
as it
On Jul 7, 2009, at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One possibility would be to remove join_collapse_limit entirely, but
that would eliminate one possibily-useful piece of functionality that
it current enables: namely, the ability to
Peter Eisentraut pete...@gmx.net wrote:
in the future we might want to change from a fixed list of patch
sections to a free list of tags, say. Then someone might alter the
application backend, and we'd use that new version for the next
commit fest at the time. What will that do to the
Le 7 juil. 09 à 19:37, Greg Stark a écrit :
I propose that there's a maximum reasonable planning time
It sounds so much like the planner_effort GUC that has been talked
about in the past...
http://archives.postgresql.org/pgsql-performance/2009-05/msg00137.php
...except this time you want
Le 7 juil. 09 à 21:16, Robert Haas a écrit :
Now, here's another thought: if we think it's reasonable for people
to want to explicitly specify the join order, a GUC isn't really the
best fit, because it's all or nothing. Maybe we'd be better off
dropping the GUCs entirely and adding some
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 07 July 2009 19:35:54 Tom Lane wrote:
I looked at this patch. I'm a bit disturbed by the
ORDER BY c.oid::pg_catalog.regclass
business. I doubt that does what the author thinks, and I'm not sure
what we really want anyway. If we want the
Peter Eisentraut pete...@gmx.net writes:
With the wiki, the data of the old fests will pretty much stay what is
was, unless we change the wiki templates in drastic ways, as I
understand it. But if we did changes like the above, or more
complicated things, perhaps, what will happen? Perhaps
Dimitri Fontaine dfonta...@hi-media.com writes:
Another idea would be to have more complex metrics for deciding when
to run geqo, that is guesstimate the query planning difficulty very
quickly, based on more than just the number of relations in the from:
presence of subqueries, UNION,
David E. Wheeler wrote:
On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
And it only goes back to 8.0
Huh, true :-( This should be fixed.
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have formal
Le 7 juil. 09 à 21:12, Tom Lane a écrit :
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
And I'm sure people will want the option to retain WAL longer in the
master, to avoid an expensive resync if the slave falls behind. It
would
be simple to provide a GUC option for always
Robert Haas robertmh...@gmail.com wrote:
if we think it's reasonable for people to want to explicitly specify
the join order
Regardless of the syntax (GUC or otherwise), that is an optimizer
hint. I thought we were trying to avoid those.
Although -- we do have all those enable_* GUC
On Jul 7, 2009, at 2:14 PM, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote:
We're now about a week away from the start of the July 2009
commitfest, and we need to make a decision about whether to start
using http://commitfest.postgresql.org to
Robert Haas escribió:
I suspect both are true, but in the unlikely event that we decide on
some massive change to the system, we can either run the DBs in parallel
as Tom suggests, or dump out the older data in Wiki markup and post it on
there. But I can't imagine what we'd want to do
Le 7 juil. 09 à 21:45, Tom Lane a écrit :
Dimitri Fontaine dfonta...@hi-media.com writes:
Another idea would be to have more complex metrics for deciding when
to run geqo
Pointless, since GEQO is only concerned with examining alternative
join
orderings. I see no reason whatever to think
On Jul 7, 2009, at 12:59 PM, Alvaro Herrera wrote:
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have
formal
control over scheduled maintenance expirations…
The web team already has a table, and it is published
Hello.
Here's a patch(WIP) that implements INSERT .. RETURNING inside a CTE.
Should apply cleanly against CVS head.
The INSERT query isn't rewritten so rules and default values don't work.
Recursive CTEs don't work either.
Regards,
Marko Tiikkaja
*** a/src/backend/commands/explain.c
---
Tom Lane t...@sss.pgh.pa.us writes:
As of CVS HEAD you get
QUERY PLAN
Result (cost=0.00..0.01 rows=1 width=0) (actual
Dimitri Fontaine dfonta...@hi-media.com writes:
Could we add yet another postmaster specialized child to handle the
archive, which would be like a default archive_command implemented in
core.
I think this fails the basic sanity check: do you need it to still work
when the master is dead.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Although -- we do have all those enable_* GUC values which are also
optimizer hints; perhaps this should be another of those?
enable_join_reorder?
Not a bad suggestion, especially since turning it off would usually be
considered just about as
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
Also, if hash indexes were a realistic alternative to btree for this,
we'd already have come up against the problem that the CONSTRAINT syntax
doesn't provide any way to specify what kind of index you want to use
underneath the constraint. I
On Jul 7, 2009, at 3:03 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Robert Haas robertmh...@gmail.com wrote:
if we think it's reasonable for people to want to explicitly specify
the join order
Regardless of the syntax (GUC or otherwise), that is an optimizer
hint. I thought we
Robert Haas robertmh...@gmail.com writes:
I guess my point is that there's not a lot of obvious benefit in
allowing the functionality to exist but handicapping it so that it's
useful in as few cases as possible. If the consensus is that we want
half a feature (but not more or less than
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
if we think it's reasonable for people to want to explicitly
specify the join order
Regardless of the syntax (GUC or otherwise), that is an optimizer
hint. I
On Wednesday 06 May 2009 18:47:57 Tom Lane wrote:
So the ambiguous-input problem is solved if we define the new format(s)
to be started by backslash and something that the old code would reject.
I'd keep it short, like \x, but there's still room for multiple
formats if anyone really wants to
Peter Eisentraut pete...@gmx.net writes:
Here is a first cut at a new hex bytea input and output format. Example:
...
SET bytea_output_hex = true;
Should the configuration parameter be a boolean or an enum, opening
possibilities for other formats?
Enum. If we do this then it seems
Tom Lane escribió:
My own thought is that from_collapse_limit has more justification,
since it basically acts to stop a subquery from being flattened when
that would make the parent query too complex, and that seems like a
more understandable and justifiable behavior than treating JOIN
I found Tom's response ambiguous - but positive in either way, so it
gave me a smile. :-)
Which of the following two great things occurred?
1) Tom popped a quick fix on CVS HEAD? (Pretty fast!)
2) Tom or somebody else had already done it?
Cheers,
mark
On 07/07/2009 05:14 PM, Sergey
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
My own thought is that from_collapse_limit has more justification,
since it basically acts to stop a subquery from being flattened when
that would make the parent query too complex, and that seems like a
more understandable
Mark Mielke m...@mark.mielke.cc writes:
Which of the following two great things occurred?
1) Tom popped a quick fix on CVS HEAD? (Pretty fast!)
2) Tom or somebody else had already done it?
http://archives.postgresql.org/pgsql-committers/2009-07/msg00067.php
First, I'm happy that you're working on this; I think it's important. I
am working on another index constraints feature that may have some
interaction:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00302.php
Let me know if you see any potential conflicts between our work.
On Tue,
On Jul 7, 2009, at 4:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I guess my point is that there's not a lot of obvious benefit in
allowing the functionality to exist but handicapping it so that it's
useful in as few cases as possible. If the consensus
Oh, now problem with simple query:
8.4.0 from Debian
explain analyze select i from t where i = 10 and i = 1;
QUERY PLAN
Result (cost=0.00..0.01 rows=1 width=0) (actual
Robert Haas robertmh...@gmail.com writes:
On Jul 7, 2009, at 4:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My own thought is that from_collapse_limit has more justification,
That's pretty much where I am with it, too. The feature I was
referring to was not the collapse limits, but the
1 - 100 of 120 matches
Mail list logo
