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
> t
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 loading
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 = (xl_btree_vacuum
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 vi
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 fo
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
On Tue, 2009-01-06 at 18:40 -0500, Tom Lane wrote:
> "Nathan Boley" 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 valu
> 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.
sp
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 s
Alex Hunsaker wrote:
> On Fri, Jan 2, 2009 at 03:13, Magnus Hagander 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 trick:
>
On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian 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 interesting and informa
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 fil
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 Su
Tom Lane wrote:
> Magnus Hagander 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 not h
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 i
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 cod
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 logi
ITAGAKI Takahiro wrote:
>
> Hiroshi Inoue 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.
shouldn't thi
ITAGAKI Takahiro wrote:
> Hiroshi Inoue 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 p
Tatsuo Ishii 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 error code.
>
* 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 inst
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, GetRunningT
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.
>
> W
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, whi
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 writes:
>>>
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 fs
Alvaro Herrera 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 the wrapping be "if (.
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
Martin Pihlak 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 age to start with. I
On Fri, Jan 2, 2009 at 5:48 PM, Martijn van Oosterhout
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
> ratio mostly.
>
>
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 s
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;
>
"Nikhil Sontakke" 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 float arithmetic can tell yo
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;
>
>>> Peter Eisentraut 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 wha
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
Pavan Deolasee wrote:
> On Wed, Jan 7, 2009 at 1:23 AM, Bruce Momjian 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 ot
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 acti
"Robert Haas" writes:
> On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian 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
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. I
Peter Eisentraut 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 have to invent
On Wed, Jan 07, 2009 at 09:56:48AM -0500, Tom Lane wrote:
> "Nikhil Sontakke" 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 te
ITAGAKI Takahiro wrote:
Hiroshi Inoue 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 patch is an updat
On Wed, Jan 07, 2009 at 11:17:46AM -0500, Tom Lane wrote:
> Peter Eisentraut 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 recursiv
Sam Mason 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 numeric literal
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 th
On 7 Jan 2009, at 09:47, Bruce Momjian 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 replication, so we might
On Wed, 2009-01-07 at 10:59 -0500, Tom Lane wrote:
> "Robert Haas" writes:
> > On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian 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 installations whose average
Greg Stark wrote:
>
> On 7 Jan 2009, at 09:47, Bruce Momjian 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" 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 default. I will
> ~ 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 s
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. Thi
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
> 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 li
* 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 beca
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 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 has a better
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 ap
> >> 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 implie
* 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 ce
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 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 query strin
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 th
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. Nob
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 what
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 t
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 modul
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
> mak
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 subtrans
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Hiroshi Inoue 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.
shouldn
Tom Lane wrote:
> Bruce Momjian 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 acces
Le 7 janv. 09 à 22:21, Simon Riggs 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 constraint_exclusion? That is
the easi
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()?
> >
> > latestCom
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 gon
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 b
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 gsm...@gre
Bruce Momjian 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 (by def
Alvaro Herrera 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 non-static variable that does
On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
Bruce Momjian 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 has sugges
Bruce Momjian 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 explains it lik
Tom Lane wrote:
> Alvaro Herrera 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
"D'Arcy J.M. Cain" writes:
> Bruce Momjian 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 produce 100%
spec-complia
On Wed, 2009-01-07 at 17:46 -0500, Tom Lane wrote:
> Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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
D'Arcy J.M. Cain wrote:
> On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
> Bruce Momjian 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 unn
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 ear
Bruce Momjian 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 call a p
1 - 100 of 132 matches
Mail list logo
