On 14 July 2016 at 14:28, Vladimir Sitnikov
wrote:
> Craig>That moves work further away from the DB, which has its own costs,
> and isn't something you're likely to be happy with if you're looking at
> things like optimising PL/PgSQL with a bytecode compiler. But it's the best
> we have right now
On 14 July 2016 at 03:26, Robert Haas wrote:
> On Fri, Jul 8, 2016 at 5:47 AM, Craig Ringer
> wrote:
> >> DDL is our standard way of getting things into the system catalogs.
> >> We have no system catalog metadata that is intended to be populated by
> >> any means other than DDL.
> >
> > Replica
Craig>That moves work further away from the DB, which has its own costs,
and isn't something you're likely to be happy with if you're looking at
things like optimising PL/PgSQL with a bytecode compiler. But it's the best
we have right now.
What if JVM was started within a background worker?
Then J
On 14 July 2016 at 03:06, Robert Haas wrote:
> Physical replication has
> the same issue. Users don't want to configure archive_command and
> wal_keep_segments and max_wal_senders and wal_level and set up an
> archive and create recovery.conf on the standby. They want to spin up
> a new standb
Hi,
So I'm generally happy with 0001, baring some relatively minor
adjustments. I am however wondering about one thing:
On 2016-07-11 23:51:05 +0900, Masahiko Sawada wrote:
> diff --git a/src/backend/access/heap/heapam.c
> b/src/backend/access/heap/heapam.c
> index 57da57a..e7cb8ca 100644
> ---
On 12 July 2016 at 21:57, wrote:
> Hi
>
> Is there any plan to implement "session per thread" or "shared
> sessions between thread"?
>
As has been noted by others, there isn't any such plan right now.
PostgreSQL isn't threaded. It uses a multi-processing
shared-nothing-by-default memory
On 14 July 2016 at 03:59, Robert Haas wrote:
> I agree that there's not really a plan to implement this, but I don't
> agree that connection pooling solves the whole problem. Most people
> can't get by with statement pooling, so in practice you are looking at
> transaction pooling or session po
Hi all,
Attached patch fixes small typo in contrib/postgres_fdw/deparse.c
s/whenver/whenever/g
Regards,
--
Masahiko Sawada
fix_small_typo_in_deparse_c.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On Jul 13, 2016, at 12:25 PM, Stephen Frost wrote:
> I disagree. Adding a column is certainly changing the structure, as is
> removing one. This certainly hasn't changed my opinion that it's
> worthwhile to consider this change, even at this point in the release
> cycle, given we need to make a
Hi,
On 2016-06-24 16:29:53 -0700, Andres Freund wrote:
> 4) Various missing micro optimizations have to be performed, for more
>architectural issues to become visible. E.g. [2] causes such bad
>slowdowns in hash-agg workloads, that other bottlenecks are hidden.
One such issue is the usage
Hi,
On 2016-06-24 16:29:53 -0700, Andres Freund wrote:
> 2) Baring 1) tuple deforming is the biggest bottleneck in nearly all
>queries I looked at. There's various places we trigger deforming,
>most ending in either slot_deform_tuple(), heap_getattr(),
>heap_deform_tuple().
>
>This
On 07/09/2016 05:42 AM, David Rowley wrote:
On 30 June 2016 at 03:49, Robert Haas wrote:
On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson wrote:
On 06/24/2016 01:31 PM, David Rowley wrote:
Seems there's a small error in the upgrade script for citext for 1.1
to 1.2 which will cause min(citex
Alvaro Herrera writes:
> Now, I think requesting psql not to split query strings is a good
> feature, but having it depend on using \; instead of ; seems way too
> obscure. If we want to offer that choice, I propose we do it via some
> properly designed mechanism rather than being a random emerge
David G. Johnston wrote:
> On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote:
>
> > Although "\;" behavior is not documented, I would have expected both
> >>> results to be shown one after the other, or having a an error, but not a
> >>> quiet discard.
> >>
> >> See the documentation for PQexe
Current plans are to produce a 9.6beta3 release next week (ie, wrap
Monday Jul 18 for announcement Thursday Jul 21). Keep in mind also
that we expect to make routine back-branch update releases on the
previously-announced schedule (wrap Monday Aug 8 for announcement
Thursday Aug 11). We'll probab
On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote:
>
> Hello Tom,
>
> Although "\;" behavior is not documented, I would have expected both
>>> results to be shown one after the other, or having a an error, but not a
>>> quiet discard.
>>>
>>
>> See the documentation for PQexec(): all but the l
On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote:
>
>> I do not think changing this is appropriate. All you are likely to
>> accomplish is breaking code that does what its author wanted.
>>
>
> Hmmm... My 0.02€: Currently this feature is NOT documented, so somehow it
> is not supported, and
Hello Tom,
Although "\;" behavior is not documented, I would have expected both
results to be shown one after the other, or having a an error, but not a
quiet discard.
See the documentation for PQexec(): all but the last query result is
discarded.
Sure. That is developer-level answer to "wh
Fabien COELHO writes:
> Hello devs,
> Although this is probably a "feature", it is a weird one:
> $ psql
> psql (9.6beta2)
> fabien=# SELECT 1 AS one \;
> fabien-# SELECT 2 AS two ;
>two
> -
> 2
> (1 row)
> Where is my "1"?
> Although "\;" behavior is not documented, I
Hello David,
At least we aggree that having a documentation would be an improvement:-)
On the second point:
- all results should be shown, not just the last one
disagree
# select 1 ; select 2 ;
vs
# select 1 \; select 2 ;
Result in identical behavior seems undesirable.
In both case
On Wed, Jul 13, 2016 at 4:02 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO
> wrote:
> >> If someone thinks that "gset" is a good idea for pgbench, which I
> don't, it
> >> could be implemented. I think that an "into" feature, like PL/pgSQL &
> ECPG,
Hello Tom,
Sending a batch of requests is a feature of libpq which is accessible
through pgbench by using "\;", although the fact is not documented. It
makes sense for a client to send independent queries together so as to
reduce latency.
You're putting an awful lot of weight on an unsupporte
Hi,
Currently, if old_snapshot_threshold is enabled, vacuum is prevented
from truncating tables:
static bool
should_attempt_truncation(LVRelStats *vacrelstats)
{
BlockNumber possibly_freeable;
possibly_freeable = vacrelstats->rel_pages -
vacrelstats->nonempty_pages;
if (p
On 2016-07-13 15:57:02 -0500, Kevin Grittner wrote:
> A short answer is that a normal table's heap doesn't go through
> systable_getnext_ordered(). That function is used both for cases
> where the check should not be made, like toast_delete_datum(), and
> cases where it should, like toast_fetch_da
Andres Freund writes:
> On 2016-07-13 16:39:58 -0400, Tom Lane wrote:
>> I think there's a lot, but I'm afraid most of them are in contexts
>> (pun intended) where aset.c already works pretty well, ie it's a
>> short-lived context anyway.
> FWIW, hacking up the aset/mcxt.c to use a trivial alloca
On Wed, Jul 13, 2016 at 10:31 PM, Simon Riggs wrote:
> On 12 July 2016 at 23:49, Michael Paquier wrote:
>> Hence why not simplifying its interface and remove the force flag?
>
> Is this change needed as part of a feature? If not, I see no reason for
> change.
>
> If we all work towards meaningful
On Thu, Jul 14, 2016 at 4:29 AM, Robert Haas wrote:
> On Fri, Jul 8, 2016 at 7:14 AM, Michael Paquier
> wrote:
>>> OK, that removes comment duplication. Also, what about replacing
>>> "bit(s)" by "one or more bits" in the comment terms where adapted?
>>> That's bikeshedding, but that's what this
On Wed, Jul 13, 2016 at 4:47 PM, Fabien COELHO wrote:
>
> I would suggest that:
> - the \; psql feature should be documented somewhere
>
agreed
> - all results should be shown, not just the last one
>
disagree
# select 1 ; select 2 ;
?column?
--
1
(1 row)
?column?
-
On Wed, Jul 13, 2016 at 12:48 PM, Andres Freund wrote:
> On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote:
>> On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote:
>>> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote:
On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote:
> I'm
On 2016-07-13 16:39:58 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
> > wrote:
> > What's not clear to me is to what extent slowing down pfree is an
> > acceptable price for improving the behavior in other ways. I wonder
> > how many of the pfree
On 13/07/16 21:06, Robert Haas wrote:
We have much to discuss in terms of security, the way it should work and
what options to support and a sidetrack into syntax isn't warranted at this
early stage. Please lets discuss those important things first, then return
to whether DDL makes sense or not
Hello devs,
Although this is probably a "feature", it is a weird one:
$ psql
psql (9.6beta2)
fabien=# SELECT 1 AS one \;
fabien-# SELECT 2 AS two ;
two
-
2
(1 row)
Where is my "1"?
Although "\;" behavior is not documented, I would have expected both
results to be shown one af
On 13 July 2016 at 15:06, Robert Haas wrote:
> On Thu, Jul 7, 2016 at 9:25 PM, Simon Riggs wrote:
> > I note also that replication slots aren't backed up by pg_dump; I see
> > analogy here and think that at least some parts of logical replication
> will
> > be similar and not require DDL at all,
Robert Haas writes:
> On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
> wrote:
> What's not clear to me is to what extent slowing down pfree is an
> acceptable price for improving the behavior in other ways. I wonder
> how many of the pfree calls in our current codebase are useless or
> even count
Robert Haas writes:
> On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Suppose we changed the default to "require". How crazy would that be?
>> You mean, aside from the fact that it breaks every single installation
>> that hasn't configured with SSL?
> No, including
Fabien COELHO writes:
> Sending a batch of requests is a feature of libpq which is accessible
> through pgbench by using "\;", although the fact is not documented. It
> makes sense for a client to send independent queries together so as to
> reduce latency.
You're putting an awful lot of weigh
Robert Haas writes:
> On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote:
>> The default mode of "prefer" is ridiculous in a lot of ways. If you are
>> using SSL in any shape or form you should simply not use "prefer". That's
>> really the only answer at this point, unfortunately.
> Suppose
Hello Robert,
I agree: I like \into.
Great!
But:
SELECT 1, 2 \; SELECT 3;
\into one two three
I think that's pretty weird.
I agree that it is weird, but I do not think that it is bad.
Sending a batch of requests is a feature of libpq which is accessible
through pgbench by using "\;
On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote:
>>> The default mode of "prefer" is ridiculous in a lot of ways. If you are
>>> using SSL in any shape or form you should simply not use "prefer". That's
>>> really t
On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
wrote:
> I think the MemoryContext API may not be right abstraction for this.
+1. The MemoryContext API is little short of an absolute bar to
implementing an allocator that works significantly differently than
aset.c, and that's a shame because aset.c
Robert Haas writes:
> On Wed, Jul 13, 2016 at 3:02 PM, Tom Lane wrote:
>> I note also that we were talking a couple months ago
>> about trying to align psql and pgbench backslash commands more closely.
>> This would not be a good step in that direction.
> True, but I'd still argue that \into is
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote:
> You would think so.
>
> The default mode of "prefer" is ridiculous in a lot of ways. If you are
> using SSL in any shape or form you should simply not use "prefer". That's
> really the only answer at this point, unfortunately.
Suppose we c
On Wed, Jul 13, 2016 at 3:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote:
>>> If someone thinks that "gset" is a good idea for pgbench, which I don't, it
>>> could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG,
>>> makes
On Tue, Jul 12, 2016 at 3:19 AM, Magnus Hagander wrote:
> +1, this is a useful warning.
+1.
I'd like to see more people turn log_checkpoints=on, and I often ask
customers to do that when they're having systemic performance
problems. But this warning regularly alerts me to cases where I've
faile
Robert Haas writes:
> On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote:
>> If someone thinks that "gset" is a good idea for pgbench, which I don't, it
>> could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG,
>> makes more sense for scripting.
> I agree: I like \into.
>
On Tue, Jul 12, 2016 at 9:18 AM, Tom Lane wrote:
> amatv...@bitec.ru writes:
>> Is there any plan to implement "session per thread" or "shared
>> sessions between thread"?
>
> No, not really. The amount of overhead that would add --- eg, the need
> for locking on what used to be single-us
On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote:
> If someone thinks that "gset" is a good idea for pgbench, which I don't, it
> could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG,
> makes more sense for scripting.
I agree: I like \into.
But:
> SELECT 1, 2 \; SELECT
On Fri, Jul 8, 2016 at 7:14 AM, Michael Paquier
wrote:
>> OK, that removes comment duplication. Also, what about replacing
>> "bit(s)" by "one or more bits" in the comment terms where adapted?
>> That's bikeshedding, but that's what this patch is about.
>
> Translating my thoughts into code, I get
On Wed, Jul 13, 2016 at 12:24 PM, Tom Lane wrote:
>> I am happy with the adjustment. Please commit the adjusted patch.
>
> Done with minor adjustments.
Thanks. I'm pleased that we found a way forward that addressed every concern.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgs
On Fri, Jul 8, 2016 at 5:47 AM, Craig Ringer wrote:
>> DDL is our standard way of getting things into the system catalogs.
>> We have no system catalog metadata that is intended to be populated by
>> any means other than DDL.
>
> Replication slots? (Arguably not catalogs, I guess)
>
> Replication
Peter Geoghegan writes:
> On Wed, Jul 13, 2016 at 11:44 AM, Tom Lane wrote:
>> If you're good with that adjustment, I'm happy to commit this.
> I am happy with the adjustment. Please commit the adjusted patch.
Done with minor adjustments.
regards, tom lane
--
Sent vi
On Thu, Jul 7, 2016 at 9:25 PM, Simon Riggs wrote:
> I note also that replication slots aren't backed up by pg_dump; I see
> analogy here and think that at least some parts of logical replication will
> be similar and not require DDL at all, just as slots do not.
I agree with that. Of course, it
On 07/07/2016 01:01 PM, Robert Haas wrote:
There was an unconference session on this topic at PGCon and quite a
number of people there stated that they found DDL to be an ease-of-use
feature and wanted to have it.
Yeah, I haven't meet anyone yet that would like to have:
select replicate_these
On Wed, Jul 13, 2016 at 11:44 AM, Tom Lane wrote:
> What I don't much like is that it enlarges cluster.out with 200K of
> random-looking, hard-to-manually-verify data. May I suggest that
> we replace the SELECTs with
>
> select * from
> (select hundred, lag(hundred) over () as lhundred,
>
On Thu, Jul 7, 2016 at 8:53 PM, Simon Riggs wrote:
>> I thought I sat through, at least, most of it, but you barely gave
>> anyone else a chance to talk, which kind of misses the point of an
>> unconference. The portion which I attended was not about how to move
>> the development of the feature
Peter Geoghegan writes:
> Attached patch adds a CLUSTER external sort test case to the
> regression tests, as discussed.
I took a quick look at this patch.
> This makes a hardly noticeable difference on the run time of the
> CLUSTER tests, at least for me. Consider the following:
I tried the pa
On 07/13/2016 07:37 PM, Tom Lane wrote:
Peter Geoghegan writes:
On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
wrote:
In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced
his dislike of dense_alloc. I kinda agree with him that introducing "local
allocators" may not be the
On Mon, Jul 11, 2016 at 8:35 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 7/9/16 4:00 PM, Andrew Gierth wrote:
>
>> How about
>>
>> Time: 1234567.666 ms (20m 34.6s)
>>
>
> That's similar to what I had in mind, so I'd be happy with that.
>
>
> --
> Peter Eisentraut
Andres Freund writes:
> On 2016-07-13 13:37:55 -0400, Tom Lane wrote:
>> We already know that
>> that code has performance issues, cf bug #14231, so I suspect there's
>> a redesign in its future anyway.
> Note that it's not the slab allocators that is having problems, it's
> aset.c, iterating thr
On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote:
> On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote:
> > On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote:
> >> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote:
> >>
> >>> I'm a bit confused, why aren't we simply adding LSN interlock
On 2016-07-12 10:04:45 -0500, Kevin Grittner wrote:
> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote:
>
> > I'm a bit confused, why aren't we simply adding LSN interlock
> > checks for toast? Doesn't look that hard? Seems like a much more
> > natural course of fixing this issue?
>
> I took
On 2016-07-13 13:37:55 -0400, Tom Lane wrote:
> I wonder though if we don't already have another similar use-case in
> the ad-hoc "slab allocators" in reorderbuffer.c.
That seems to call more for a general slab allocator design, than for
something like here. After all, there's plenty of freeing th
Peter Geoghegan writes:
> On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
> wrote:
>> In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced
>> his dislike of dense_alloc. I kinda agree with him that introducing "local
>> allocators" may not be the best idea, and as dense_alloc w
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
> > I'm curious how it's useful and in what way \sf does not accomplish what
> > you use \df+ for.
>
> One main use is to see multiple related functions next to each other and
> compare their so
On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
wrote:
> In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced
> his dislike of dense_alloc. I kinda agree with him that introducing "local
> allocators" may not be the best idea, and as dense_alloc was introduced by
> me I was play
Peter Eisentraut writes:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
>> I'm curious how it's useful and in what way \sf does not accomplish what
>> you use \df+ for.
> One main use is to see multiple related functions next to each other and
> compare their source code. But also because one is use
Peter Geoghegan writes:
> On Wed, Jul 13, 2016 at 2:49 AM, Bjørnar Ness wrote:
>> But with upsert/do nothing, this will not work as "needed".
>>
>> Would it be possible to introduce a "ON CONFLICT SELECT" argument:
>>
>> with _foo as (
>> insert into foo(i) values(1)
>> on conflict select retu
On Wed, Jul 13, 2016 at 2:49 AM, Bjørnar Ness wrote:
> But with upsert/do nothing, this will not work as "needed".
>
> Would it be possible to introduce a "ON CONFLICT SELECT" argument:
>
> with _foo as (
> insert into foo(i) values(1)
> on conflict select returning id
> ) insert into bar(foo_
Mike Blackwell writes:
> There are times when it would be useful to have the application_name
> connection parameter displayed in the process name - and thus in ps and
> pg_top - in addition to the user and database name.
> Would there be any downside to this?
In a lot of situations ("top" for i
On 7/12/16 7:11 PM, Stephen Frost wrote:
> I'm curious how it's useful and in what way \sf does not accomplish what
> you use \df+ for.
One main use is to see multiple related functions next to each other and
compare their source code. But also because one is used to \df and
wants to see everythi
There are times when it would be useful to have the application_name
connection parameter displayed in the process name - and thus in ps and
pg_top - in addition to the user and database name.
Would there be any downside to this? If it were done, are there any
suggestions on how it could be added
On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote:
> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote:
>> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote:
>>
>>> I'm a bit confused, why aren't we simply adding LSN interlock
>>> checks for toast? Doesn't look that hard? Seems like a muc
Albe Laurenz writes:
> I just noticed that the documentation for CREATE FUNCTION still mentions
> that the temporary namespace is searched for functions even though that
> has been removed with commit aa27977.
The example you propose to correct was introduced by that same commit,
which should mak
Hi,
In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom
voiced his dislike of dense_alloc. I kinda agree with him that
introducing "local allocators" may not be the best idea, and as
dense_alloc was introduced by me I was playing with the idea to wrap
this into a regular memory
On 12 July 2016 at 23:49, Michael Paquier wrote:
> Hence why not simplifying its interface and remove the force flag?
Is this change needed as part of a feature? If not, I see no reason for
change.
If we all work towards meaningful features the code can be cleaned up as we
go.
--
Simon Rigg
On Wed, Jul 13, 2016 at 8:27 PM, Amit Kapila wrote:
> On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier
> wrote:
>> Hence why not simplifying its interface and remove the force flag?
>
> One point to note is that the signature and usage of
> UpdateMinRecoveryPoint() is same as it was when it got i
Your patch is very helpful, I'm still checking it on different file-systems.
I really liked the idea of using only the edge checkpoints.
Thanks.
On Mon, Jul 11, 2016 at 9:26 PM, Jeff Janes wrote:
> On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg
> wrote:
> > Hi All,
> >
> > As part of my maste
The new upsert feature is a great addition, but in some cases is not
as usable as
I and seems lots of others would like it to be, take an example with
circular references:
create table foo (
id serial references bar(foo_id) on delete cascade,
i int
);
create table bar (
foo_id integer refer
On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote:
> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote:
>
>> I'm a bit confused, why aren't we simply adding LSN interlock
>> checks for toast? Doesn't look that hard? Seems like a much more
>> natural course of fixing this issue?
>
> I took s
On Tue, Jul 12, 2016 at 10:23 PM, Jeff Janes wrote:
> I've been having some adventures with pg_basebackup lately, and had
> some suggestions based on those.
>
> The --help message for pg_basebackup says:
>
> -Z, --compress=0-9 compress tar output with given compression level
>
> But -Z0 is the
On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier
wrote:
> Hi all,
>
> As of now UpdateMinRecoveryPoint() is using two arguments:
> - lsn, to check if the minimum recovery point should be updated to that
> - force, a boolean flag to decide if the update should be enforced or not.
> However those tw
Hi,
Consider a scenario where one adds a *valid* constraint on a inheritance
parent which is then merged with a child table's *not valid* constraint
during inheritance recursion. If merged, the constraint is not checked
for the child data even though it may have some. Is that an oversight?
Tha
> Seems odd to me. Both relations use the same user mapping as before, so
> the join should be pushed down.
>
> Another thing I noticed is that the code in plancache.c would invalidate a
> cached plan with a foreign join due to user mapping changes even in the
> case where user mappings are meanin
Hello Peter,
number of transactions per client: 1000
-latency average = 15.844 ms
+latency average: 15.844 ms
tps = 618.764555 (including connections establishing)
I think what you have here is that colons separate input parameters and
equal signs separate result output. So I think it's OK
The attached patch provides a solution which ensures the return in the right
condition and after the stat collection. The code structure requires another
ugly boolean to proceed so as to preserve doing the reconnection between the
decision that the return must be done and the place where it ca
Hello Tom,
Ok. Here is an updated version, with a better suffix and a simplified
comment.
Doesn't this break the handling of latency calculations, or at least make
the results completely different for the last metacommand than what they
would be for a non-last command? It looks like it needs
I just noticed that the documentation for CREATE FUNCTION still mentions
that the temporary namespace is searched for functions even though that
has been removed with commit aa27977.
Attached is a patch to fix that.
Yours,
Laurenz Albe
0001-Fix-mention-of-pg_temp-in-CREATE-FUNCTION-documentat.p
87 matches
Mail list logo
