On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH t AS (DELETE FROM foo)
SELECT * FROM foo;
And the big question is: what state of foo should the SELECT
On 2010-11-11 23:21, Tom Lane wrote:
I've been thinking about supporting automatic replan of cached plans
using specific parameter values, as has been discussed several times,
at greatest length in this thread:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00607.php
..
I want to
On 11/10/2010 10:58 PM, Peter Eisentraut wrote:
One thing to aim for, perhaps, would be to make all tools in use produce
a common output format, at least optionally, so that creating a common
test run dashboard or something like that is more easily possible. TAP
and xUnit come to mind.
Note
OK, I see. Thanks for mentioning it.
Are there other problems with the suggestion? Or should the work like that?
Viktor
2010/11/10 Robert Haas robertmh...@gmail.com
On Wed, Nov 10, 2010 at 6:32 AM, Viktor Valy vili0...@gmail.com wrote:
Thanks for your answer!
I'm not really familiar with
I revised my patch according to the prior suggestions.
Invocation of the hooks is encapsulated within macro, not function:
+ #define InvokeObjectAccessHook0(access,classId,objectId,subId)\
+ do {\
+ if
(2010/11/12 19:34), KaiGai Kohei wrote:
I revised my patch according to the prior suggestions.
I'm sorry. I revised my patch, but not attached.
Please see this attached one.
Thanks,
Invocation of the hooks is encapsulated within macro, not function:
+ #define
Markus Wanner wrote:
Note that dtester features a TAP reporter. However, the way Kevin
uses dtester, that probably won't give useful results. (As he uses
custom print statements to do more detailed reporting than TAP
could ever give you).
According to the TAP draft standard, any line not
On Wed, Nov 10, 2010 at 4:04 AM, Bruce Momjian br...@momjian.us wrote:
We last researched index-only scans, also called covering indexes, in
September of 2008, but have made little progress on it since. Many have
been waiting for Heikki to implement this but I talked to him and he
doesn't
On 11/12/2010 02:27 PM, Kevin Grittner wrote:
According to the TAP draft standard, any line not beginning with
'ok', 'not ok', or '#' is a comment and must be ignored by a TAP
consumer. They are considered comments, and the assumption is that
there can be many of them.
I stand corrected. Do
Markus Wanner wrote:
I stand corrected. Do you actually use the TapReporter?
No. I know so little about TAP that I wasn't aware that dtester
output was in the TAP format until I saw your post on this thread, so
I went searching for the format to see what I might do to become more
compliant
Excerpts from Greg Stark's message of vie nov 12 10:33:28 -0300 2010:
In Postgres, aside from the visibility issues we have a separate
problem. In order to achieve high concurrency we allow splits to occur
without locking the index. And the new pages can be found anywhere in
the index, even
On 12.11.2010 15:51, Alvaro Herrera wrote:
Excerpts from Greg Stark's message of vie nov 12 10:33:28 -0300 2010:
In Postgres, aside from the visibility issues we have a separate
problem. In order to achieve high concurrency we allow splits to occur
without locking the index. And the new pages
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report whether IPv4 or IPv6 are
being used.
What's the use of that exactly? It doesn't really respond to Peter's
concern, I think.
Peter liked:
And I agree it's not very friendly in this
Robert Haas wrote:
On Thu, Nov 11, 2010 at 10:13 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus j...@agliodbs.com wrote:
I sort of agree with you that the current checkpoint_segments
parameter is a bit hard to tune, at least
On 11/12/2010 02:43 PM, Kevin Grittner wrote:
Markus Wanner wrote:
I stand corrected. Do you actually use the TapReporter?
No. I know so little about TAP that I wasn't aware that dtester
output was in the TAP format
Well, there are three kinds of reporters: StreamReporter, TapReporter
Magnus Hagander wrote:
On Fri, Nov 12, 2010 at 03:49, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
ashesh.va...@enterprisedb.com wrote:
Hi Mark,
On of my college (Sujeet) has found a way to reproduce the same
Greg Stark wrote:
On Wed, Nov 10, 2010 at 4:04 AM, Bruce Momjian br...@momjian.us wrote:
We last researched index-only scans, also called covering indexes, in
September of 2008, but have made little progress on it since. ?Many have
been waiting for Heikki to implement this but I talked to
Markus Wanner wrote:
Well, there are three kinds of reporters: StreamReporter,
TapReporter and CursesReporter. By default, either curser or stream
is chosen, depending on whether or not dtester thinks its stdout is
a terminal or not.
The CursesReporter moves up and down the lines to
On 11/12/2010 09:17 AM, Bruce Momjian wrote:
Greg Stark wrote:
On Wed, Nov 10, 2010 at 4:04 AM, Bruce Momjianbr...@momjian.us wrote:
We last researched index-only scans, also called covering indexes, in
September of 2008, but have made little progress on it since. ?Many have
been waiting
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 12, 2010 at 12:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The problem is not with the type system: as long as you give multisets
different type OIDs from arrays, everything will work fine.
And thus you must create a THIRD copy of every
Excerpts from Heikki Linnakangas's message of vie nov 12 11:01:39 -0300 2010:
It took me a while to understand what Greg meant as well. You can't scan
a B-tree index in *physical order*, You have to first descend to the
leftmost leaf, and follow the right pointers from there until you reach
Bruce Momjian br...@momjian.us writes:
Uh, I still cannot reproduce the failure:
I would imagine you need -w option on the start. The whole issue
here is whether start's wait-for-server-start code works.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH t AS (DELETE FROM foo)
SELECT * FROM foo;
And the big question
On Fri, Nov 12, 2010 at 8:33 AM, Greg Stark gsst...@mit.edu wrote:
On Wed, Nov 10, 2010 at 4:04 AM, Bruce Momjian br...@momjian.us wrote:
We last researched index-only scans, also called covering indexes, in
September of 2008, but have made little progress on it since. Many have
been waiting
On Fri, Nov 12, 2010 at 4:28 AM, Viktor Valy vili0...@gmail.com wrote:
OK, I see. Thanks for mentioning it.
Are there other problems with the suggestion? Or should the work like that?
I think you'll just need to give it a try and see how it goes. I
think we've covered most of the possible
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The simplest case to point out this behaviour is:
WITH t
On Fri, Nov 12, 2010 at 10:50:52AM -0500, Robert Haas wrote:
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications
On Fri, Nov 12, 2010 at 12:45 AM, Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
Hi Mark,
Il 12/11/10 03:31, mark ha scritto:
I have listed what I think I will be doing with regards to initdb. if
anyone
sees problems with the following mixture during my dump - init-
restore
Hi Gentlemen,
Thank you for the time estimate and the interface discussion. It
sounds like the PostgreSQL SQL/MED code will be very useful when it
is done. Our product provides read-only access to files, so
updates/inserts/deletes aren't an issue for us.
One thing that is not clear to me is
On Fri, Nov 12, 2010 at 12:53:09AM -0500, Robert Haas wrote:
On Fri, Nov 12, 2010 at 12:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 11, 2010 at 10:02 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
If we reuse type IDs of arrays
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age, or possibly
design compromises that seemed reasonable a decade or more ago, but
are less so now.
To
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Uh, I still cannot reproduce the failure:
I would imagine you need -w option on the start. The whole issue
here is whether start's wait-for-server-start code works.
Thanks, I am now able to reproduce this. I was able to get this to
2010/11/13 Robert Haas robertmh...@gmail.com:
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main point is whether they see the data
modifications or not. The
On 11/12/2010 11:34 AM, David Fetter wrote:
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age, or possibly
design compromises that seemed reasonable
Robert, it is great you are taking this on. This is really a well-known
area of the code for you, but not so much for Teodor and Oleg, so I am
sure they appreciate your assistance.
---
Robert Haas wrote:
On Sat, Oct 16,
mark wrote:
A fix being so that col LIKE 'foo%' could use btree indexes in
locales like en_US.UTF8 (and probably some others).
How about specifying an opclass?:
http://www.postgresql.org/docs/current/interactive/indexes-opclass.html
-Kevin
--
Sent via pgsql-hackers mailing list
Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
rhaas=# create table concurrent (x integer primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
concurrent_pkey for table concurrent
CREATE TABLE
rhaas=# insert into x values (1);
rhaas=# begin;
1. Is KNNGIST intended to work if there's more than one pathkey? If
so, how? Example:
SELECT * FROM tab ORDER BY this_point- '(0,0)', this_point- '(1,1)'
Why not, if distances from two points to '(0,0)' are equal, it's need to compare
distances to '(1,1)'. Nothing new here, KNN-GiST
Josh Berkus wrote:
On 10/08/2010 02:44 PM, Robert Haas wrote:
In any case, I would expect that GIN could actually do this quite
efficiently. What we'd probably want is a concept of a null word,
with empty indexable rows entered in the index as if they contained the
null word. So
On 11/12/2010 01:11 PM, Bruce Momjian wrote:
Josh Berkus wrote:
On 10/08/2010 02:44 PM, Robert Haas wrote:
In any case, I would expect that GIN could actually do this quite
efficiently. What we'd probably want is a concept of a null word,
with empty indexable rows entered in the index
Andrew Dunstan wrote:
On 11/12/2010 01:11 PM, Bruce Momjian wrote:
Josh Berkus wrote:
On 10/08/2010 02:44 PM, Robert Haas wrote:
In any case, I would expect that GIN could actually do this quite
efficiently. What we'd probably want is a concept of a null word,
with empty
Slightly-more-fleshed out proof of concept patch attached, with actual
syntax, documentation, and pg_dump support added. This might be
thought of as a subset of the builtin_knngist_core patch, without the
parts that make it actually do something useful (which is mostly
match_pathkey_to_index -
Hi all,
It appears that we have a consensus on the behaviour.
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Bruce Momjian br...@momjian.us writes:
OK, can you add it or give me wording, or it is already on the TODO
list?
It's already there.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sat, Nov 13, 2010 at 01:50:46AM +0900, Hitoshi Harada wrote:
2010/11/13 Robert Haas robertmh...@gmail.com:
On Fri, Nov 12, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
On 2010-11-11 17:50, Marko Tiikkaja wrote:
Just to be clear, the main
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/24/2010 08:12 PM, Tom Lane wrote:
This shows that the bitmapset optimization really is quite effective,
at least for cases where all the enum labels are sorted by OID after
all. That motivated me to change the bitmapset
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/24/2010 08:12 PM, Tom Lane wrote:
This shows that the bitmapset optimization really is quite effective,
at least for cases where all the enum labels are sorted by OID after
all. That motivated me to change the bitmapset
On 11/12/2010 01:40 PM, Bruce Momjian wrote:
FYI, I marked the TODO item for adding enums as completed. The TODO
item used to also mention renaming or removing enums, but I have seen
few requests for that so I removed that suggestion. We can always
re-add it if there is demand.
Renaming
With how similar straight C and en_US.UTF8 are it was suggested to me,
by persons who are far more C knowledgeable then I in my office, that
this is something the PG community could fix . A fix being so that
col LIKE 'foo%' could use btree indexes in locales like en_US.UTF8
(and probably
Andrew Dunstan and...@dunslane.net writes:
On 11/12/2010 01:40 PM, Bruce Momjian wrote:
FYI, I marked the TODO item for adding enums as completed. The TODO
item used to also mention renaming or removing enums, but I have seen
few requests for that so I removed that suggestion. We can always
On Nov 12, 2010, at 6:28 AM, Kevin Grittner wrote:
The CursesReporter moves up and down the lines to write results to
concurrently running tests. It's only useful on a terminal and
certainly gets confused by anything that moves the cursor (which a
plain 'print' certainly does).
Ah, well
On Fri, Nov 12, 2010 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/12/2010 01:40 PM, Bruce Momjian wrote:
FYI, I marked the TODO item for adding enums as completed. The TODO
item used to also mention renaming or removing enums, but I have seen
Robert Haas robertmh...@gmail.com writes:
With how similar straight C and en_US.UTF8 are it was suggested to me,
by persons who are far more C knowledgeable then I in my office, that
this is something the PG community could fix . A fix being so that
col LIKE 'foo%' could use btree indexes in
On Fri, Nov 12, 2010 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
With how similar straight C and en_US.UTF8 are it was suggested to me,
by persons who are far more C knowledgeable then I in my office, that
this is something the PG community could
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 12, 2010 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, you can rename an item today if you don't mind doing a direct
UPDATE on pg_enum. I think that's probably sufficient if the demand
only amounts to one or two requests a year.
On 11.11.2010 20:34, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Hmm, we don't currently keep track of that when we descend the tree to
choose the target page, but perhaps an extra Consistent call to check
that would be acceptable. We already call Penalty for
Tom Lane t...@sss.pgh.pa.us writes:
WITH t AS (DELETE FROM foo RETURNING *)
SELECT * FROM t LIMIT 1;
How many rows does this delete? I think we concluded that we should
force the DELETE to be run to conclusion even if the outer query didn't
read it all
The counter-example that
Andrew Dunstan and...@dunslane.net writes:
This is so general as to be quite meaningless to me. What is it that is
wanted that we don't have. (And don't say flexibility, that's way too
general - say something much more concrete and specific. If you want
flexibility we can store everything as
David E. Wheeler wrote:
On Nov 12, 2010, at 6:28 AM, Kevin Grittner wrote:
I'll switch to TapReporter.
Oh, that would be great, because I can then have the TAP stuff I
plan to add just run your tests and harness the results along with
everything else.
I switched it with this patch:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
WITH t AS (DELETE FROM foo RETURNING *)
SELECT * FROM t LIMIT 1;
How many rows does this delete? I think we concluded that we should
force the DELETE to be run to conclusion even if the outer query didn't
This patch:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=bb0fe9feb9fd75a6aaa960028a9f810c883b0fc4
...did not tidy up after itself as well as it might have. In
particular, it left the prototype for copydir() in src/include/port.h,
while moving the source file from
Robert Haas robertmh...@gmail.com writes:
This patch:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=bb0fe9feb9fd75a6aaa960028a9f810c883b0fc4
...did not tidy up after itself as well as it might have. In
particular, it left the prototype for copydir() in src/include/port.h,
Tom Lane t...@sss.pgh.pa.us writes:
I can see that there's a fair argument for that position in cases like
the above, but the trouble is that there are also cases where it's very
hard for the user to predict how many rows will be read. As examples,
mergejoins may stop short of reading all of
On Fri, Nov 12, 2010 at 4:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This patch:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=bb0fe9feb9fd75a6aaa960028a9f810c883b0fc4
...did not tidy up after itself as well as it might have. In
On Nov 12, 2010, at 12:39 PM, Kevin Grittner wrote:
(2) If I wanted something to show in the TAP output, like the three
counts at the end of the test, what's the right way to do that? (I
suspect that printing with a '#' character at the front of the line
would do it, but that's probably not
Excerpts from Tom Lane's message of jue nov 11 19:21:34 -0300 2010:
I've been thinking about supporting automatic replan of cached plans
using specific parameter values, as has been discussed several times,
at greatest length in this thread:
Excerpts from Bruce Momjian's message of vie nov 12 15:40:28 -0300 2010:
FYI, I marked the TODO item for adding enums as completed. The TODO
item used to also mention renaming or removing enums, but I have seen
few requests for that so I removed that suggestion. We can always
re-add it if
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of jue nov 11 19:21:34 -0300 2010:
I think that what we need to do is restructure the API of
plancache.c to make it more amenable to returning throwaway plans.
I was wondering if this could help with the
Hi,
Stefan Kaltenbrunner reported a problem in postmaster via IM to me. I
thought I had nailed down the bug, but after more careful reading of the
code, turns out I was wrong.
The reported problem is that postmaster shuts itself down with this
error message:
2010-11-12 10:19:05 CET FATAL: no
On Nov 12, 2010, at 2:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 12, 2010 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, you can rename an item today if you don't mind doing a direct
UPDATE on pg_enum. I think that's probably
On Fri, 2010-11-12 at 14:20 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 12, 2010 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, you can rename an item today if you don't mind doing a direct
UPDATE on pg_enum. I think that's probably sufficient if the
On Fri, Nov 12, 2010 at 7:20 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think we can work around that with a small modification to the page split
algorithm. In a nutshell, when the child page is split, put a flag on the
left half indicating that the rightlink must
On Fri, 2010-11-12 at 12:03 -0500, Andrew Dunstan wrote:
On 11/12/2010 11:34 AM, David Fetter wrote:
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to
On Fri, Nov 12, 2010 at 6:12 PM, Jeff Davis pg...@j-davis.com wrote:
That being said, a few details are left to be decided (an
understatement).
Best... comment... ever.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
On Fri, 2010-11-12 at 08:34 -0800, David Fetter wrote:
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age, or possibly
design compromises that
It's the time of year again where leaves are falling, temperatures
dropping, and patches cry out looking for one last review before the
start of the holiday season. The patches submitted so far are listed at
https://commitfest.postgresql.org/action/commitfest_view?id=8 ,
featuring a mix of
I wrote:
(1) Any idea why it finds the success of the tests unexpected?
Should anyone else run into this, it's controlled by this in the test
scheduling definitions (the tdef values):
'xfail': True
There are other test flags you can override here, like 'skip' to skip
a test.
-Kevin
--
Excerpts from Dimitri Fontaine's message of vie nov 12 17:13:59 -0300 2010:
Tom Lane t...@sss.pgh.pa.us writes:
WITH t AS (DELETE FROM foo RETURNING *)
SELECT * FROM t LIMIT 1;
How many rows does this delete? I think we concluded that we should
force the DELETE to be run to
On 11/12/2010 07:07 PM, Jeff Davis wrote:
On Fri, 2010-11-12 at 08:34 -0800, David Fetter wrote:
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age,
Joshua D. Drake wrote:
On Fri, 2010-11-12 at 14:20 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 12, 2010 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, you can rename an item today if you don't mind doing a direct
UPDATE on pg_enum. I think that's
On 11/12/2010 09:18 PM, Bruce Momjian wrote:
OK, got it. Added incomplete TODO item:
Allow renaming and deleting enumerated values from an existing
enumerated data type
I have serious doubts that deleting will ever be sanely doable.
cheers
andrew
--
Sent via
Andrew Dunstan wrote:
On 11/12/2010 09:18 PM, Bruce Momjian wrote:
OK, got it. Added incomplete TODO item:
Allow renaming and deleting enumerated values from an existing
enumerated data type
I have serious doubts that deleting will ever be sanely doable.
True. Should
The attached patch allows the security label provider to switch
security label of the client during execution of certain functions.
I named it as label switcher function; also called as trusted-
procedure in SELinux community.
This feature is quite similar idea toward security definer function,
Tom Lane wrote:
Leonardo Francalanci m_li...@yahoo.it writes:
Cases with lots of irrelevant indexes. Zoltan's example had 4 indexes
per child table, only one of which was relevant to the query. In your
test case there are no irrelevant indexes, which is why the runtime
didn't change.
Bruce Momjian br...@momjian.us writes:
FYI, I always wondered if the rare use of mergejoins justified the extra
planning time of carrying around all those joinpaths.
They're hardly rare.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Josh Berkus wrote:
None of us know. What I do know is that I don't want PostgreSQL to be
slower out of the box.
Understandable. So it seems like the answer is getting replication down
to one configuration variable for the common case. That eliminates the
cycle of oops, need to set X
Andrew Dunstan and...@dunslane.net writes:
On 11/12/2010 03:16 PM, Peter Eisentraut wrote:
Improved parallel make support
Looks like this patch has pretty comprehensively broken the MSVC build
system. I'll see what I can recover from the wreckage.
There are also at least three non-Windows
Bruce Momjian br...@momjian.us writes:
Right. I propose that we set max_wal_senders to unlimited when
wal_level = hot_standby.
It's a memory allocation parameter ... you can't just set it to
unlimited, at least not without a nontrivial amount of work.
regards, tom lane
89 matches
Mail list logo
