On Wed, 2009-01-07 at 09:34 +0200, Heikki Linnakangas wrote:
autovacuum_freeze_max_age - autovacuum_freeze_scan_age
vacuum_freeze_max_age - vacuum_freeze_scan_age
vacuum_freeze_min_age - vacuum_freeze_tuple_age
*_scan_age settings control when the table is fully scanned to freeze
tuples
Peter Eisentraut wrote:
Eventually, the postgresql_fdw library should contain an implementation that
actually connects to a PostgreSQL database and does useful things (dblink
replacement, basically). Right now, we are proposing to use it as connection
information storage. But I think
Hi,
KaiGai Kohei wrote:
The attached patch is a proof of the concept.
Awesome! I'll try to review during the day.
I strongly want the Column-level privileges to be get merged
as soon as possible, so I don't spare any possible assist
for his works.
+1
Can you quickly comment on CLP vs.
Tom Lane wrote:
This is actually in direct contradiction to the original intent of the
plugins/ subdirectory, which was that it only contain libraries that the
local administrator had decided to consider safe and put there manually.
Since the normal superuser-only restrictions for library
Markus Wanner wrote:
Hi,
KaiGai Kohei wrote:
The attached patch is a proof of the concept.
Awesome! I'll try to review during the day.
I strongly want the Column-level privileges to be get merged
as soon as possible, so I don't spare any possible assist
for his works.
+1
Can you quickly
Simon Riggs wrote:
* btree VACUUM code - must scan every block of index (v6)
Need to unlock them too.
--- a/src/backend/access/nbtree/nbtxlog.c
+++ b/src/backend/access/nbtree/nbtxlog.c
@@ -472,7 +472,7 @@ btree_xlog_vacuum(XLogRecPtr lsn, XLogRecord *record)
xlrec =
Greg Smith wrote:
I think I'm now up to having wrote something to break apart the output
from version() into individual fields for 3 different companies. If
you're got a bunch of database servers on a network, it seems inevitable
that eventually you'll end up collecting information about them
On Wed, 2009-01-07 at 11:35 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
* btree VACUUM code - must scan every block of index (v6)
Need to unlock them too.
Oh c**p. Thanks.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via
Bruce Momjian wrote:
Andrew Dunstan wrote:
Cleaning up the parallel restore patch I came across a question I might
have asked before, but one which in any case I worked around:
Why do we carefully define fseeko() for WIN32 but then not define
HAVE_FSEEKO, which makes doing the former
Alvaro Herrera wrote:
Tom Lane escribió:
(In fact, maybe this patch ought to include some sort of maximum update
rate tunable? The worst case behavior could actually be WORSE than now.)
Some sort of if stats were requested in the last 500 ms, just tell the
requester to read the existing
On Tue, 2009-01-06 at 18:40 -0500, Tom Lane wrote:
Nathan Boley npbo...@gmail.com writes:
I don't think this is a bug.
hmmm... Well, I assumed it was a bug from a comment in analyze.
From ( near ) line 2130 in analyze.c
* least 2 instances in the sample. Also, we won't suppress
Surely the most important point in the OP was that ineqsel does not
correctly binary search in the presence of duplicates.
It would have been if I were correct :-( .
Looking at it again, that was from a bug in my code. Thanks for your
time, and sorry about the noise.
-Nathan
--
Sent via
Robert Haas píše v út 06. 01. 2009 v 12:38 -0500:
- WIP: Page space reservation (pgupgrade) is an idea that was
rejected, IIRC. pg_upgrade project status is more of the same thing.
there are several more pg_upgrade related items on here as well, most
of which are probably unnecessary.
space
There's still something wrong with the way subtransactions are handled.
I got:
postgres=# SELECT * FROM foo;
ERROR: could not access status of transaction 118649
DETAIL: Could not open file pg_subtrans/0001: No such file or directory.
in the standby after some testing.
I created a lot of
Alex Hunsaker wrote:
On Fri, Jan 2, 2009 at 03:13, Magnus Hagander mag...@hagander.net wrote:
Andrew Chernow wrote:
Yes, the homedir variable is used again later in the function. homedir
could be invalid since pqGetHomeDirectory might not get called. Maybe
something like below would do the
On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian br...@momjian.us wrote:
Based on the comments below, are we sure constraint_exclusion still
needs to be a parameter and can't be on by default?
The benchmarking we did to determine the impact of raising
default_statistics_target was pretty
On Wed, 2009-01-07 at 13:18 +0200, Heikki Linnakangas wrote:
There's still something wrong with the way subtransactions are handled.
I got:
postgres=# SELECT * FROM foo;
ERROR: could not access status of transaction 118649
DETAIL: Could not open file pg_subtrans/0001: No such file or
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch.
v6b now available via Wiki, fixes 5 reported issues.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Alvaro Herrera wrote:
Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?
I thought about that, but I don't want to add extra gucs without a good
reason. You'd typically
Martin Pihlak wrote:
Usually it would have been the server owner who created those user
mappings in the first place -- so the passwords are already known
to him/her. Of course it is possible to create the mappings first
and later change the ownership of the server, thus exposing the
passwords to
Joe Conway wrote:
I don't see anything documented under GRANT which controls privileges on
a mapping, and the USAGE on a server only controls what a user can see
by query. I assume that if the superuser creates a mapping from user foo
to server bar, foo can still use bar via the mapping, even
Error code 25001 is used for SET TRANSACTION ISOLATION LEVEL must be
called before any query when it's an ERROR. However, it also means
there is already a transaction in progress when it's a NOTICE.
So we cannot distinguish them just by checking the error code.
So my question is, an error code
Kevin Grittner wrote:
is a natural consequence of the fact --- There is nothing natural
about any of this. Why is it a consequence and how?
How could you possibly get any of those phenomena if there are no
concurrent transactions?
I see what you mean now, but you could write out that logic
ITAGAKI Takahiro wrote:
Hiroshi Inoue in...@tpf.co.jp wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
ITAGAKI Takahiro wrote:
Hiroshi Inoue in...@tpf.co.jp wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
The
Tatsuo Ishii is...@postgresql.org writes:
Error code 25001 is used for SET TRANSACTION ISOLATION LEVEL must be
called before any query when it's an ERROR. However, it also means
there is already a transaction in progress when it's a NOTICE.
So we cannot distinguish them just by checking the
* Bruce Momjian (br...@momjian.us) wrote:
Based on the comments below, are we sure constraint_exclusion still
needs to be a parameter and can't be on by default?
I'd like to get rid of the option and have it on by default. It's a bit
frustrating to have to remember to turn it on with new
Another annoyance I noticed while testing the case of a lot of
subtransactions (overflowing the procarray cache) is that when you have
a transaction with a lot of subtransactions open, getting the initial
snapshot fails, and the standby doesn't open for read-only queries.
Normally,
KaiGai Kohei wrote:
Alvaro Herrera wrote:
3. Why the StdRdOptions lopts; is necessary?
It is like this because the autovacuum patch adds a few more options and
I want to have the chance to not allocate the part belonging to
autovacuum when none of the options are present.
We can return
Magnus Hagander wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Cleaning up the parallel restore patch I came across a question I might
have asked before, but one which in any case I worked around:
Why do we carefully define fseeko() for WIN32 but then not define
HAVE_FSEEKO,
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Hi,
I posted a patch 18 days ago but have got no responce.
Anyway I've simplified the patch by using an appropriate
gettext module.
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Thomas H.
Andrew Dunstan wrote:
Magnus Hagander wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Cleaning up the parallel restore patch I came across a question I
might have asked before, but one which in any case I worked around:
Why do we carefully define fseeko() for WIN32 but then
Alvaro Herrera alvhe...@commandprompt.com writes:
Oh, the patch also removes a bunch of continue statements that, as far
as I can tell, no longer work after the macros were wrapped in
do { ... } while (0) :-( I don't see any nice way to put the facility
back.
Hmm ... I guess you could make
On Tue, Jan 06, 2009 at 11:49:57PM -0500, Robert Haas wrote:
Josh / eggyknap -
Can you rerun your performance tests with this version of the patch?
...Robert
Will do, as soon as I can.
signature.asc
Description: Digital signature
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Is it possible to implement a walker function to pick up appeared
columns and to chain them on rte-cols_sel/cols_mod?
In this idea, columns in Query-targetList should be chained on
rte-cols_mod, and others should be chained on rte-cols_sel.
Martin Pihlak martin.pih...@gmail.com writes:
As I understand the autovacuum workers need up to date stats to minimize the
risk of re-vacuuming a table (in case it was already vacuumed by someone
else).
I never understood why autovacuum should need a particularly short fuse
on the stats file
On Fri, Jan 2, 2009 at 5:48 PM, Martijn van Oosterhout
klep...@svana.org wrote:
So you compromise. You split the data into say 1MB blobs and compress
each individually. Then if someone does a substring at offset 3MB you
can find it quickly. This barely costs you anything in the compression
Heikki Linnakangas wrote:
It's required by the sync replication patch, but has no value otherwise.
Well, we have talked about allowing more signalling long-term, and this
would accomplish that independent of the sync replication, so we might
want to revisit this someday if it isn't included in
Hi,
Consider the following with latest CVS sources:
postgres=# create table temp(val float4);
CREATE TABLE
postgres=# insert into temp values (415.1);
INSERT 0 1
postgres=# select * from temp where val = 415.1;
val
-
(0 rows)
!?
The reason seems to be that 415.1 ends up being treated as a
On Wed, Jan 07, 2009 at 08:12:44PM +0530, Nikhil Sontakke wrote:
Hi,
Consider the following with latest CVS sources:
postgres=# create table temp(val float4);
CREATE TABLE
postgres=# insert into temp values (415.1);
INSERT 0 1
postgres=# select * from temp where val = 415.1;
val
Nikhil Sontakke nikhil.sonta...@enterprisedb.com writes:
Consider the following with latest CVS sources:
postgres=# create table temp(val float4);
CREATE TABLE
postgres=# insert into temp values (415.1);
INSERT 0 1
postgres=# select * from temp where val = 415.1;
Anybody who works with
On Wed, Jan 07, 2009 at 08:12:44PM +0530, Nikhil Sontakke wrote:
Hi,
Consider the following with latest CVS sources:
postgres=# create table temp(val float4);
CREATE TABLE
postgres=# insert into temp values (415.1);
INSERT 0 1
postgres=# select * from temp where val = 415.1;
val
Peter Eisentraut pete...@gmx.net wrote:
Kevin Grittner wrote:
is a natural consequence of the fact --- There is nothing
natural about any of this. Why is it a consequence and how?
How could you possibly get any of those phenomena if there are no
concurrent transactions?
I see what
Zdenek Kotala wrote:
Robert Haas p??e v ?t 06. 01. 2009 v 12:38 -0500:
- WIP: Page space reservation (pgupgrade) is an idea that was
rejected, IIRC. pg_upgrade project status is more of the same thing.
there are several more pg_upgrade related items on here as well, most
of which are
Pavan Deolasee wrote:
On Wed, Jan 7, 2009 at 1:23 AM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
As-is, this list is completely unhelpful. It looks like you've dumped
all your unread mail onto this page and asked the rest of us to sort it
for you. I'm sorry, but I've got
Tom Lane wrote:
I note though that we have a lot of other non-recursive maintenance
operations (CLUSTER, some variants of ALTER TABLE, etc) ... are we
going to try to make them all recursive?
Here is the current line-up:
command supports ONLY
ALTER TABLE all other
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian br...@momjian.us wrote:
Based on the comments below, are we sure constraint_exclusion still
needs to be a parameter and can't be on by default?
The benchmarking we did to determine the impact of raising
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Where are we on this?
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext module.
Peter Eisentraut pete...@gmx.net writes:
[ good summary ]
+1 for making TRUNCATE and LOCK support ONLY. I don't care much about
ALTER TABLE SET SCHEMA, but perhaps there's a use-case for recursion
on that. We should stay away from recursive CREATE INDEX for the
moment --- for one thing, you'd
On Wed, Jan 07, 2009 at 09:56:48AM -0500, Tom Lane wrote:
Nikhil Sontakke nikhil.sonta...@enterprisedb.com writes:
Consider the following with latest CVS sources:
postgres=# create table temp(val float4);
CREATE TABLE
postgres=# insert into temp values (415.1);
INSERT 0 1
postgres=#
ITAGAKI Takahiro wrote:
Hiroshi Inoue in...@tpf.co.jp wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
The attached
On Wed, Jan 07, 2009 at 11:17:46AM -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
[ good summary ]
+1 for making TRUNCATE and LOCK support ONLY. I don't care much
about ALTER TABLE SET SCHEMA, but perhaps there's a use-case for
recursion on that. We should stay away from
Sam Mason s...@samason.me.uk writes:
This example does seem to be confounded by PG's somewhat eccentric type
system. Things would just work (in this case, and there have been
other cases recently[1]) if type decisions could be delayed slightly.
There's been previous speculation about having
I've also thought a similar implementation but there seems
a problem of efficiency.
As far as I see wcsftime() is almost = strftime() + mbstowcs()
and so using strftime() is effective at least for the following
cases.
1) LC_CTIME is C.
2) LC_CTYPE != C and the database encoding != UTF-8. In
On 7 Jan 2009, at 09:47, Bruce Momjian br...@momjian.us wrote:
Heikki Linnakangas wrote:
It's required by the sync replication patch, but has no value
otherwise.
Well, we have talked about allowing more signalling long-term, and
this
would accomplish that independent of the sync
On Wed, 2009-01-07 at 10:59 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian br...@momjian.us wrote:
Based on the comments below, are we sure constraint_exclusion still
needs to be a parameter and can't be on by default?
In
Greg Stark wrote:
On 7 Jan 2009, at 09:47, Bruce Momjian br...@momjian.us wrote:
Heikki Linnakangas wrote:
It's required by the sync replication patch, but has no value
otherwise.
Well, we have talked about allowing more signalling long-term, and
this
would accomplish that
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-01-07 at 10:59 -0500, Tom Lane wrote:
In installations whose average query is significantly heavier-weight
than this one, and where constraint exclusion actually improves matters
on a routine basis, it makes sense to turn it on by
~ 10% slowdown on trivial queries will get noticed.
Agreed.
I just thought of a possible compromise though: maybe we could invent an
intermediate constraint_exclusion setting that makes the checks only for
inheritance-child tables. This would avoid the overhead for simple
queries and still
On Wed, 2009-01-07 at 12:26 -0500, Robert Haas wrote:
~ 10% slowdown on trivial queries will get noticed.
I just thought of a possible compromise though: maybe we could invent an
intermediate constraint_exclusion setting that makes the checks only for
inheritance-child tables. This would
I wrote:
I just thought of a possible compromise though: maybe we could invent an
intermediate constraint_exclusion setting that makes the checks only for
inheritance-child tables. This would avoid the overhead for simple
queries and still get the benefit for most of the cases where it's
Tom Lane wrote:
I wrote:
I just thought of a possible compromise though: maybe we could invent an
intermediate constraint_exclusion setting that makes the checks only for
inheritance-child tables. This would avoid the overhead for simple
queries and still get the benefit for most of the
So, barring objections, I'll go make this happen. What do we want to
call the intermediate constraint_exclusion value? The first thing
that comes to mind is constraint_exclusion = 'child', but perhaps
someone has a better idea.
inherit?
...Robert
--
Sent via pgsql-hackers mailing list
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Actually, it looks like it'd be totally trivial to implement: just check
rel-reloptkind == RELOPT_OTHER_MEMBER_REL to detect whether we're
looking at an inheritance child. (Actually this would also succeed
for a UNION ALL member, but that's good because
So, barring objections, I'll go make this happen. What do we want to
call the intermediate constraint_exclusion value? The first thing
that comes to mind is constraint_exclusion = 'child', but perhaps
someone has a better idea.
This is terrific. I've actually been turning c_e on and off by
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
So, barring objections, I'll go make this happen. What do we want to
call the intermediate constraint_exclusion value? The first thing
that comes to mind is constraint_exclusion = 'child', but perhaps
someone
Tom,
Hm, how about just 'partition'? Your argument is fair, and another
point in its favor is that someday we'll probably have an explicit
notion of partitioned tables and both the inheritance and union-view
approaches would become legacy methods. We'd certainly want constraint
exclusion to
So, barring objections, I'll go make this happen. What do we want to
call the intermediate constraint_exclusion value? The first thing
that comes to mind is constraint_exclusion = 'child', but perhaps
someone has a better idea.
Not a huge fan of 'child' since it implies inheritance.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Hm, how about just 'partition'? Your argument is fair, and another
point in its favor is that someday we'll probably have an explicit
notion of partitioned tables and both the inheritance and union-view
approaches would become legacy methods. We'd
Tom Lane wrote:
Log Message:
---
Adjust things so that the query_string of a cached plan and the sourceText of
a portal are never NULL, but reliably provide the source text of the query.
It turns out that there was only one place that was really taking a short-cut,
which was the
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.
I looked at the use of 'debug_query_string'; I didn't see how
current_query() could access the more concise
Magnus Hagander wrote:
Hiroshi Inoue wrote:
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext module. I can provide it
if requested.
Yes, I think
On Wed, 2009-01-07 at 12:54 -0500, Tom Lane wrote:
So, barring objections, I'll go make this happen.
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion? That is
the easiest part of the whole process by a long way.
I just noticed that optimizer/cost.h is not #include'd by plancat.c,
which is not too cool because the former has the extern declaration
for the constraint_exclusion global variable while the latter has
the actual definition. I didn't run it down in the CVS history to
make sure, but I imagine
Simon Riggs wrote:
On Wed, 2009-01-07 at 12:54 -0500, Tom Lane wrote:
So, barring objections, I'll go make this happen.
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion? That is
the easiest part of the whole
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext module. I can provide it
if
Tom Lane wrote:
I just noticed that optimizer/cost.h is not #include'd by plancat.c,
which is not too cool because the former has the extern declaration
for the constraint_exclusion global variable while the latter has
the actual definition. I didn't run it down in the CVS history to
make
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
Another annoyance I noticed while testing
I'm sorry this has annoyed you. Thanks for testing.
the case of a lot of
subtransactions (overflowing the procarray cache) is that when you have
a transaction with a lot of
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Hiroshi Inoue in...@tpf.co.jp wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.
I looked at the use of 'debug_query_string'; I didn't see how
current_query() could
Le 7 janv. 09 à 22:21, Simon Riggs si...@2ndquadrant.com a écrit :
On Wed, 2009-01-07 at 12:54 -0500, Tom Lane wrote:
So, barring objections, I'll go make this happen.
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on
Simon Riggs wrote:
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
When there's no xids in the procarray, couldn't we just use
latestCompletedXid instead of calling ReadNewTransactionId()?
latestCompletedXid is protected by ProcArrayLock so not much difference
between those two.
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext module. I
Bruce Momjian wrote:
The script certainly has no way to know it is missing an extern, and I
am not sure how I would even teach it that trick.
The example you saw was:
src/include/optimizer/cost.h:55:extern bool constraint_exclusion;
src/backend/optimizer/util/plancat.c:46:bool
On Wed, 2009-01-07 at 23:56 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
When there's no xids in the procarray, couldn't we just use
latestCompletedXid instead of calling ReadNewTransactionId()?
latestCompletedXid is
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion? That is
the easiest part of the whole process by a long way. Nobody has this
table design by accident, they've
D'Arcy J.M. Cain wrote:
So what have we decided about this suggestion. Should I submit the
patch or just forget about it? So far some people like it and some
people think that it is unneccessary. No one so far has suggested that
it would harm the system or people's use of it.
I have gone
Stephen Frost wrote:
-- Start of PGP signed section.
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion? That is
the easiest part of the whole process by a long
On Wed, 7 Jan 2009, Simon Riggs wrote:
Who can set up an inherited table structure but can't remember to turn
on constraint_exclusion?
I thought the whole point of the WIP Auto Partitioning Patch was exactly
to enable larger numbers of such people in the future.
--
* Greg Smith
Bruce Momjian br...@momjian.us writes:
* Simon Riggs (si...@2ndquadrant.com) wrote:
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion?
This new change also adds the constraint exclusion overhead only for
inhertance
Alvaro Herrera alvhe...@commandprompt.com writes:
Bruce Momjian wrote:
The script certainly has no way to know it is missing an extern, and I
am not sure how I would even teach it that trick.
It would be easy if the compiler were to have an option to throw a
warning when it finds a
On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
Bruce Momjian br...@momjian.us wrote:
D'Arcy J.M. Cain wrote:
So what have we decided about this suggestion. Should I submit the
patch or just forget about it? So far some people like it and some
people think that it is unneccessary. No one so far
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
The alternative I was envisioning was to have it look at the
ActivePortal's query string. However, if you prefer to define the
function as returning the current client query, it's fine as-is.
We should make sure the documentation
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Bruce Momjian wrote:
The script certainly has no way to know it is missing an extern, and I
am not sure how I would even teach it that trick.
It would be easy if the compiler were to have an option to throw a
warning
D'Arcy J.M. Cain da...@druid.net writes:
Bruce Momjian br...@momjian.us wrote:
As I remember, no actual patch was posted for this.
There was. I am attaching it again in case there were any changes to
original files in the meantime.
I think what Bruce meant to say is that this patch doesn't
On Wed, 2009-01-07 at 17:46 -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
* Simon Riggs (si...@2ndquadrant.com) wrote:
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion?
This new change also
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
The alternative I was envisioning was to have it look at the
ActivePortal's query string. However, if you prefer to define the
function as returning the current client query, it's fine as-is.
We should make sure the
D'Arcy J.M. Cain wrote:
On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
Bruce Momjian br...@momjian.us wrote:
D'Arcy J.M. Cain wrote:
So what have we decided about this suggestion. Should I submit the
patch or just forget about it? So far some people like it and some
people think that it is
Jaime Casanova wrote:
Anyway i tried to run with
--truncate-before-load and got a message about that should be
necessary to run TRUNCATE CASCADE instead.
Actually, this raises an interesting point. It doesn't seem safe to
truncate before loading unless we have just created the table
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Well, hold on a minute. I said that was an alternative to look at,
not that it was necessarily better. Can you define in words of one
syllable which queries will be exposed this way? I don't believe
it's all of them.
Well, if you
1 - 100 of 132 matches
Mail list logo
