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
On Tue, Jul 7, 2009 at 8:28 AM, Heikki
Linnakangas 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 there's no
> download link fo
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 w
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-Meske
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 Lane wrote:
>> Fujii Masao 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 should we handle restore_c
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 a
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 ne
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 mu
On Tue, Jul 7, 2009 at 10:09 AM, Heikki
Linnakangas 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
> passwords as the clients send
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 Potdar
> wrote:
>
Greg Stark wrote:
> On Tue, Jul 7, 2009 at 10:09 AM, Heikki
> Linnakangas 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
>> passwo
-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
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 s
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 chan
Hi,
Thanks for the comment!
On Tue, Jul 7, 2009 at 5:07 PM, Heikki
Linnakangas 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 archive configured to begin with. If y
In response to Itagaki Takahiro :
> 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, us
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 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.
> There are c
Robert Haas 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 mentioned here:
Peter Eisentraut 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
>> wording chang
Atsushi Ogawa 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 happens.
Try
Dave Page writes:
> On Tue, Jul 7, 2009 at 8:28 AM, Heikki
> Linnakangas 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 others are still committing fixes to 7.4 bra
On Jul 7, 2009, at 9:31 AM, "Kevin Grittner" > wrote:
Robert Haas 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 t
Simon Riggs 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 rather than just f
Hi Kevin, Hi all,
On Tuesday 07 July 2009 16:31:14 Kevin Grittner wrote:
> Robert Haas 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 rem
Andres Freund 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 specific examples
Fujii Masao writes:
> On Tue, Jul 7, 2009 at 12:16 AM, Tom Lane 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 exist only in the
> primary server
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 done
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
improveme
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 five-y
On Tuesday 07 July 2009 17:40:50 Tom Lane wrote:
> Andres Freund 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_
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 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 seemed to start w
Brendan Jurd 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 again. :-/
Do
2009/7/8 Kevin Grittner :
> 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 describe the symptoms you obs
Brendan Jurd 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 the main page, an
"Kevin Grittner" 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 that it must have been
On Tue, Jul 7, 2009 at 4:16 PM, Tom Lane 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 kluge, and
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 to
Peter Eisentraut 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 bit d
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
On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane 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 perspective. Performan
Jeff Davis 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 try to le
Robert Haas 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. So one possibility
On Tue, 2009-07-07 at 11:16 -0400, Tom Lane wrote:
> Simon Riggs 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
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 Lane 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 point of these p
Heikki Linnakangas 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() are SQL functions and w
Greg Stark 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 the current
>
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
> Jeff Davis 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 ap
On Tuesday 07 July 2009 19:45:44 Tom Lane wrote:
> Greg Stark 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 ta
On Tue, Jul 7, 2009 at 6:22 PM, Tom Lane 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 suppose that you'd c
Greg Stark writes:
> On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane 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 slaves. We want slaves to be ab
On Monday 06 July 2009 22:16:12 Tom Lane wrote:
> Peter Eisentraut 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, this
> >
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
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 m
Jeff Davis 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 known a
Tom Lane wrote:
> Greg Stark writes:
>> On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane 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 slave
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
On Tuesday 07 July 2009 19:35:54 Tom Lane wrote:
> Peter Eisentraut 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 maintenanc
Heikki Linnakangas 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, we would want to provide some m
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 isn'
On Jul 7, 2009, at 12:32 PM, Tom Lane wrote:
Robert Haas 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
Peter Eisentraut 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 data of old
> c
On Tue, 2009-07-07 at 14:57 -0400, Tom Lane wrote:
> I don't think this even approximates the need --- in particular it's not
> clear what the semantics of combination across different index columns
> are. I assume you've hot-wired it so that several BTEqualStrategyNumber
> columns will work like
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 ot
Peter Eisentraut 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 child ta
Peter Eisentraut 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 we simply
> d
Dimitri Fontaine 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, EXISTS, IN, or branch
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 forma
Le 7 juil. 09 à 21:12, Tom Lane a écrit :
Heikki Linnakangas 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
Robert Haas 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 values which are also
op
On Jul 7, 2009, at 2:14 PM, Peter Eisentraut 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 manage it, or punt 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 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 that number-of-relations
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
--- b/s
Tom Lane writes:
> As of CVS HEAD you get
>
> QUERY PLAN
>
>
> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.011..0.011 rows=0
>
Dimitri Fontaine 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. It's reasonable to a
"Kevin Grittner" 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 bad an idea as turning
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.
On Jul 7, 2009, at 3:03 PM, "Kevin Grittner" > wrote:
Robert Haas 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.
I guess my point i
Robert Haas 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 half), that's OK w
Robert Haas wrote:
> "Kevin Grittner" > Robert Haas 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.
>
> I guess my poin
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
Peter Eisentraut 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 entirely fair tha
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
> s
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 Bur
Alvaro Herrera 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 and justifiable be
Mark Mielke 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
regards, tom lane
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, 2009-
On Jul 7, 2009, at 4:56 PM, Tom Lane wrote:
Robert Haas 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 m
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 time
1 - 100 of 123 matches
Mail list logo
