I'm playing around with tablespace (postgresq 9.4) and I found out what I
believe is a bug in pg_tables.
Basically if you create a database in a table space X and then you create a
table on the database the table is created correctly on the tablespace X (
I did a check on the filesystem) however if
On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote:
>> In any case, at this point 9.5 is really aimed to be stabilized, so
>> targeting only master is a far saner approach IMO for this patch.
>> Pushing that in 9.5 a couple of months back may have given enough
>> reason to do so... But well l
On Wed, Dec 16, 2015 at 11:20 PM, Michael Paquier
wrote:
> (A couple of months later)
> This is not an actual fix, but an optimization, no?
> UNIQUE_CHECK_SPECULATIVE is just used to optimize a couple of code
> paths in the case of a insert conflicting during btree insertion..
>
> In any case, at
On 2015-12-17 16:22:24 +0900, Michael Paquier wrote:
> On Thu, Dec 17, 2015 at 4:10 PM, Andres Freund wrote:
> > On 2015-12-17 15:56:35 +0900, Michael Paquier wrote:
> >> On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote:
> >> > For me, rewriting the visibility map is a new data loss bug waiting
On Thu, Dec 17, 2015 at 4:10 PM, Andres Freund wrote:
> On 2015-12-17 15:56:35 +0900, Michael Paquier wrote:
>> On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote:
>> > For me, rewriting the visibility map is a new data loss bug waiting to
>> > happen. I am worried that the group is not taking se
On Sun, Oct 4, 2015 at 2:07 AM, Peter Geoghegan wrote:
> On Sat, Oct 3, 2015 at 6:38 AM, Andres Freund wrote:
>> I'm not arguing against any of this - but I don't think this needs to be
>> on the 9.5 open items list. I plan to remove from there.
>
> Obviously I don't think that this is a critical
On 2015-12-17 15:56:35 +0900, Michael Paquier wrote:
> On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote:
> > For me, rewriting the visibility map is a new data loss bug waiting to
> > happen. I am worried that the group is not taking seriously the potential
> > for catastrophe here.
>
> FWIW, I
On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote:
> For me, rewriting the visibility map is a new data loss bug waiting to
> happen. I am worried that the group is not taking seriously the potential
> for catastrophe here.
FWIW, I'm following this line and merging the vm file into a single
unit
On Thu, Sep 3, 2015 at 6:10 AM, Vladimir Borodin wrote:
> Patch with implementation attached.
> Sorry for delay, I will link it to the current commitfest.
This patch looks correct, and is doing what it claims it does. It is
also not really worth refactoring the bit of code in PrefetchBuffer
that d
On 9 December 2015 at 18:31, Robert Haas wrote:
> On Mon, Nov 30, 2015 at 12:58 PM, Bruce Momjian wrote:
> > On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko Sawada wrote:
> >> On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes
> wrote:
> >> > On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada <
> saw
On Thu, Dec 17, 2015 at 3:06 PM, Kyotaro HORIGUCHI
wrote:
> At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier
> wrote in
>
>> On Mon, Dec 14, 2015 at 8:10 AM, Thomas Munro
>> wrote:
>> Yeah, I guess that's an improvement for those cases, and there is no
>> immediate need for a per-keyword
On Thu, Dec 10, 2015 at 3:31 AM, Robert Haas wrote:
> On Mon, Nov 30, 2015 at 12:58 PM, Bruce Momjian wrote:
>> On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko Sawada wrote:
>>> On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote:
>>> > On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada
>>> > w
On 17 December 2015 at 00:17, Tomas Vondra
wrote:
> 1) nodeHashjoin.c (and other join nodes)
>>
>> I've noticed we have this in the ExecHashJoin() method:
>>
>> /*
>>* When the inner side is unique or we're performing a
>>* semijoin, we'll consider returning the fir
Hello.
Ok, I withdraw the minilang solution and I'll go on Thomas's way,
which is still good to have.
At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier
wrote in
> On Mon, Dec 14, 2015 at 8:10 AM, Thomas Munro
> wrote:
> > I've also add (very) primitive negative pattern support and used it i
On Wed, Dec 16, 2015 at 9:55 PM, Dilip Kumar wrote:
> On Wed, Dec 16, 2015 at 6:20 PM Amit Kapila
> wrote:
>
> >On Tue, Dec 15, 2015 at 7:31 PM, Robert Haas
> wrote:
> >>
> >> On Mon, Dec 14, 2015 at 8:38 AM, Amit Kapila
> wrote:
>
> > In any case,
> >I have done some more investigation of the
On Thu, Dec 17, 2015 at 1:54 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas wrote:
>> > On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier
>> > wrote:
>> >> I have looked for now at the first patch and finished with the
>> >> attached while look
On Thu, Dec 17, 2015 at 1:42 PM, Michael Paquier
wrote:
> In conclusion, for this CF the patch doing the documentation fixes is
> "Ready for committer", the second patch introducing the function
> infrastructure should focus more on its core structure and should be
> marked as "Returned with feedb
Michael Paquier wrote:
> On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas wrote:
> > On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier
> > wrote:
> >> I have looked for now at the first patch and finished with the
> >> attached while looking at it. Perhaps a committer could look already
> >> at that?
Hi,
This is my first post to -hackers.
I found typos in privileges.sql and privileges.out
Please find attached a patch.
Best regards,
Tatsuro Yamada
*** a/src/test/regress/expected/privileges.out
--- b/src/test/regress/expected/privileges.out
***
*** 390,396 INSERT INTO atest5(
On Wed, Dec 16, 2015 at 3:07 PM, Fabien COELHO wrote:
>
>> On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas
>> wrote:
>>>
>>> It looks fine to me except that I think we should spell out "param" as
>>> "parameter" throughout, instead of abbreviating.
>>
>>
>> Fine for me. I have updated the first patc
On 12/16/15 12:15 AM, Jeff Janes wrote:
But also, while loading 1.5 million records into a table with 250
million records is horribly, rebuilding all the indexes on a 251.5
million record table from scratch is even more horrible. I don't know
if suspending maintenance (either globally or just fo
On 12/16/15 7:03 AM, Tomas Vondra wrote:
While versioning or increasing the 1GB limit are interesting, they have
nothing to do with this particular patch. (BTW I don't see how the
versioning would work at varlena level - that's something that needs to
be handled at data type level).
Right, but
On 12/16/15 6:01 PM, Robert Haas wrote:
On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier
wrote:
On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby wrote:
On 12/11/15 2:57 PM, Tom Lane wrote:
Jim Nasby writes:
Perhaps, but I'd like to have a less ad-hoc process about it. What's
our policy for dropp
On Wed, Dec 16, 2015 at 10:17 PM, Andres Freund wrote:
> Again. Unless I miss something that was solved in
> www.postgresql.org/message-id/flat/20130615102028.gk19...@alap2.anarazel.de
>
> Personally I think we should add lz4 and maybe on strongly compressing
> algorithm and be done with it. Runti
On 15 December 2015 at 20:17, Andres Freund wrote:
>
>
> I think this is quite the wrong approach. You're calling the logical
> decoding callback directly from decode.c, circumventing
> reorderbuffer.c. While you don't need the actual reordering, you *do*
> need the snapshot integration.
Yeah. I
Rebased patch is attached as it is having an OID conflict with the
latest set of changes
in the master branch.
Regards,
Hari Babu
Fujitsu Australia
4_database_catalog_tenancy_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi,
On 12/16/2015 11:40 PM, David Rowley wrote:
On 17 December 2015 at 05:02, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
0) I know the patch does not tweak costing - any plans in this
direction? Would it be possible to simply use the costing used by
semijoin?
On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier
wrote:
> On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby wrote:
>> On 12/11/15 2:57 PM, Tom Lane wrote:
>>> Jim Nasby writes:
>>> Perhaps, but I'd like to have a less ad-hoc process about it. What's
>>> our policy for dropping backwards-compatibility
On 17 December 2015 at 05:02, Tomas Vondra
wrote:
> 0) I know the patch does not tweak costing - any plans in this
>
direction? Would it be possible to simply use the costing used by
>semijoin?
>
>
Many thanks for looking at this.
The patch does tweak the costings so that unique joins are
On 22 August 2015 at 15:14, Andres Freund wrote:
> TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(), which
> writes an 8 byte variable (the lsn). That's not safe.
>
This point was the main sticking point here.
It turns out that we don't need to store the LSN (8 bytes).
WAL is fs
On Wed, Dec 16, 2015 at 1:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> I like option #2. I don't really have a strong reason for that, but
>> it feels intuitive to me that we err on the side of using remote
>> estimates when in doubt.
>
> If we believe that, why isn't the default value of use
On Wed, Dec 16, 2015 at 12:28 PM, Robert Haas wrote:
>> I seem to be able to produce these sorting patches at a much greater
>> rate than they can be committed, in part because Robert is the only
>> one that ever reviews them, and he is only one person.
>
> I object to that vicious slander. I am
I wrote:
> Merlin Moncure writes:
>> See https://bugs.python.org/issue23735 for background. Apparently
>> this is expected behavior (and we are far from the only ones
>> complaining about it):
>> "And so we reach where we are. If a SIGWINCH arrives while readline is
>> not active, and the applic
On Tue, Nov 17, 2015 at 6:50 PM, Peter Geoghegan wrote:
> On Tue, Nov 17, 2015 at 12:53 AM, Simon Riggs wrote:
>> Short and sweet! Looks good.
>
> Thanks.
>
>> I would be inclined to add more comments to explain it, these things have a
>> habit of being forgotten.
>
> I'm not sure what additional
Merlin Moncure writes:
> On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote:
>> So I now think that print.c shouldn't be involved at all, and the right
>> thing to do is just have gets_interactive() invoke the resize function
>> immediately before calling readline(). That will still leave a window
Alvaro Herrera writes:
>> I did some more experimentation and concluded that actually, this problem
>> has nothing whatsoever to do with pager invocations. What seems to really
>> be happening is that libreadline activates its SIGWINCH handler only while
>> it's being called to collect input, whi
On Wed, Dec 16, 2015 at 9:36 AM, Robert Haas wrote:
>> That isn't what is intended. "void" is the state that macros like
>> index_getattr() leave NULL leading attributes (that go in the
>> SortTuple.datum1 field) in.
>
> What kind of state is that? Can't we define this in terms of what it
> is ra
Alvaro Herrera wrote:
> I wonder if we're doing the proper things. According to their manual,
> http://git.savannah.gnu.org/gitweb/?p=readline.git;a=blob_plain;f=doc/readline.html;h=9b7dd842764c81ad496c38a2794361cad964ee90;hb=7628b745a813aac53586b640da056a975f1c443e#SEC44
Note: the above link do
Tom Lane wrote:
> I did some more experimentation and concluded that actually, this problem
> has nothing whatsoever to do with pager invocations. What seems to really
> be happening is that libreadline activates its SIGWINCH handler only while
> it's being called to collect input, which is fine i
Hi,
On 12/01/2015 10:34 AM, Shulgin, Oleksandr wrote:
I have the plans to make something from this on top of
pg_stat_statements and auto_explain, as I've mentioned last time. The
next iteration will be based on the two latest patches above, so it
still makes sense to review them.
As for EXPLA
On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote:
> I did some more experimentation and concluded that actually, this problem
> has nothing whatsoever to do with pager invocations. What seems to really
> be happening is that libreadline activates its SIGWINCH handler only while
> it's being called
I did some more experimentation and concluded that actually, this problem
has nothing whatsoever to do with pager invocations. What seems to really
be happening is that libreadline activates its SIGWINCH handler only while
it's being called to collect input, which is fine in itself, but *it does
n
Hello Tomas,
I'm planning to do some thorough benchmarking of the patches proposed in this
thread, on various types of hardware (10k SAS drives and SSDs). But is that
actually needed? I see Andres did some testing, as he posted summary of the
results on 11/12, but I don't see any actual resul
On Wed, Dec 16, 2015 at 12:06 PM, Andres Freund wrote:
> On 2015-12-16 13:02:25 -0500, Tom Lane wrote:
>> I think the most reasonable way to handle this is to put the
>> call into a new function exported from input.c, where it can be
>> made conditional on useReadline.
>
> Sounds good.
I'll right
On Sat, Dec 12, 2015 at 8:03 AM, Amit Kapila wrote:
>> I think it might be
>> advantageous to have at least two groups because otherwise things
>> might slow down when some transactions are rolling over to a new page
>> while others are still in flight for the previous page. Perhaps we
>> shoul
On Fri, Dec 11, 2015 at 11:56 AM, Masahiko Sawada wrote:
> On Thu, Dec 10, 2015 at 11:07 PM, Robert Haas wrote:
>> On Tue, Dec 8, 2015 at 8:32 AM, Masahiko Sawada
>> wrote:
>>> I found some lacks of tab-completion for RLS in 9.5.
>>>
>>> * ALTER POLICY [TAB]
>>> I expected to appear the list of
Robert Haas writes:
> I like option #2. I don't really have a strong reason for that, but
> it feels intuitive to me that we err on the side of using remote
> estimates when in doubt.
If we believe that, why isn't the default value of use_remote_estimate true?
(Maybe it should be.)
Another opti
Hi,
I'm planning to do some thorough benchmarking of the patches proposed in
this thread, on various types of hardware (10k SAS drives and SSDs). But
is that actually needed? I see Andres did some testing, as he posted
summary of the results on 11/12, but I don't see any actual results or
eve
On 2015-12-16 13:02:25 -0500, Tom Lane wrote:
> > If we really want to we could basically directly use
> > _rl_get_screen_size() - which seems to have been present from before
> > 4.0. It's not declared static...
>
> Nah, I don't think we should rely on calling undocumented internal
> readline fun
Andres Freund writes:
> On 2015-12-16 12:23:28 -0500, Tom Lane wrote:
>> It may be that we can't fix this in readline versions that precede the
>> introduction of the resize function. Let me go experiment on my pet
>> dinosaurs.
> I'm not particularly bothered by not supporting old readline vers
On 2015-12-11 10:08:32 -0800, Jeff Janes wrote:
> This is still in regular mode, correct?
Yes.
> I don't think this has ever worked. Vacuum needs to start a
> transaction in order to record its update of datfrozenxid and
> relfrozenxid to the catalogs (or at least, starts one for something).
> O
On Fri, Dec 11, 2015 at 4:44 AM, Ashutosh Bapat
wrote:
> Hi All,
> postgres_fdw documentation says following about use_remote_estimate
> (http://www.postgresql.org/docs/devel/static/postgres-fdw.html)
> --
> use_remote_estimate
> This option, which can be specified for a foreign table or a foreign
On Fri, Dec 11, 2015 at 1:08 PM, Jeff Janes wrote:
> Since changes to datfrozenxid are WAL logged at the time they occur,
> but the supposedly-synchronous change to ShmemVariableCache is not WAL
> logged until the next checkpoint, a well timed crash can leave you in
> the state where the system is
On Wed, Dec 9, 2015 at 5:15 PM, Peter Geoghegan wrote:
> On Wed, Dec 9, 2015 at 11:31 AM, Robert Haas wrote:
>> I find the references to a "void" representation in this patch to be
>> completely opaque. I see that there are some such references in
>> tuplesort.c already, and most likely they wer
On 2015-12-16 12:23:28 -0500, Tom Lane wrote:
> It may be that we can't fix this in readline versions that precede the
> introduction of the resize function. Let me go experiment on my pet
> dinosaurs.
I'm not particularly bothered by not supporting old readline versions
here. If we really want t
On 2015-12-16 12:02:26 -0500, Tom Lane wrote:
> [ squint... ] What readline version are you using, and do you have
> LINES/COLUMNS set in your terminal environment?
libreadline-dev:
Installed: 6.3-8+b4
Both are set - I think bash does that.
> It may be that the echo stuff is not good, but I'm
Andres Freund writes:
> ... based on that I'm inclined to just go with resize - redisplaying the
> query after the pager might be desirable, but I think it's an actual
> behavioural change.
Hmm ... given that we've not printed "Time:" yet (in \timing mode),
I think you're right that we don't want
Andres Freund writes:
> Hm. rl_reset_screen_size() works well for me. rl_resize_terminal() not
> so much. Apparently the reason for that is that rl_reset_screen_size()
> doesn't set ignore_env to to true when calling
> _rl_get_screen_size(). I've verified that just toggling that parameter
> chang
On 2015-12-16 11:21:53 -0500, Tom Lane wrote:
> It looks to me like what it's doing is repainting the current line
> on the theory that it might be messed up. Since we are, at this
> point, presumably *not* in the middle of accepting a command line,
> that should be unnecessary but also harmless.
On Wed, Dec 16, 2015 at 6:20 PM Amit Kapila wrote:
>On Tue, Dec 15, 2015 at 7:31 PM, Robert Haas wrote:
>>
>> On Mon, Dec 14, 2015 at 8:38 AM, Amit Kapila
wrote:
> In any case,
>I have done some more investigation of the patch and found that even
>without changing query planner related paramet
Hi,
First off: Glad that you investigated, this has been bugging me.
On 2015-12-14 15:57:22 -0600, Merlin Moncure wrote:
> Also, after some experimentation I had better luck with
> rl_reset_screen_size() (vs rl_resize_terminal()) that seemed to give
> more regular behavior with the prompt. So th
Andreas Karlsson writes:
> Did you manage to figure out why one was better than the other? The
> differences between the functions seem rather subtle.
I'm a bit suspicious of Merlin's recommendation as well. Looking at
the readline 6.3 sources, it is rl_resize_terminal() not the other
one that
Hi,
On 12/16/2015 01:27 AM, David Rowley wrote:
I've attached a rebased patch against current master as there were
some conflicts from the recent changes to LATERAL join.
Thanks. I've looked at the rebased patch and have a few minor comments.
0) I know the patch does not tweak costing - any
> I don't think that's what the comment says, actually. It rather refers to
> code like this:
>
>result = Min(LL_COORD(c, n - 1), UR_COORD(c, n - 1));
>
> i.e. if you specifically ask for a particular corner (ll, in this case),
> you'll get the proper value.
Hmm, I was confused by phrase “
Noah Misch wrote:
> fcinfo->flinfo->fn_oid==InvalidOid implies an inline block, and those have no
> arguments. If it placates Coverity, I lean toward an assert-only change:
>
> --- a/src/pl/plperl/plperl.c
> +++ b/src/pl/plperl/plperl.c
This was committed as d4b686af0b.
--
Álvaro Herrera
Hi,
On 12/16/2015 01:26 PM, Stas Kelvich wrote:
Hi, thanks for the review.
1) (nitpicking) There seem to be some minor whitespace issues, i.e.
trailing spaces, empty lines being added/removed, etc.
Fixed, I think
2) one of the regression tests started to fail
SELECT '-1e-700'::cube
On Wed, Dec 16, 2015 at 6:04 PM, Robert Haas wrote:
>
> On Wed, Dec 16, 2015 at 1:34 AM, Amit Kapila
wrote:
> > Yes, thats one thing I wanted to know, yet another point which is not
> > clear to me about this Async infrastructure is why the current
> > infrastructure
> > of Parallelism can't be u
On 2015-12-16 14:14:36 +0100, Tomas Vondra wrote:
> I think the main obstacle to make this possible is the lack of free space in
> varlena header / need to add the ID of the compression method into the
> value.
>
> FWIW I'd like to allow this (mixing compression types), but I don't think
> it's wo
Hi,
On 12/13/2015 06:28 PM, Alexander Korotkov wrote:
>
Compression method of column would be stored in pg_attribute table.
Dependencies between columns and compression methods would be tracked in
pg_depend preventing dropping compression method which is currently in
use. Compression method of t
On 12/14/2015 07:28 PM, Jim Nasby wrote:
On 12/14/15 12:50 AM, Craig Ringer wrote:
The issue with per-Datum is that TOAST claims two bits of a varlena
header, which already limits us to 1 GiB varlena values, something
people are starting to find to be a problem. There's no wiggle room to
steal
On Wed, Dec 16, 2015 at 3:34 AM, amul sul wrote:
> Updated patch to add this table creation case in regression tests.
> PFA patch version V3.
I committed the previous version just now after fixing various things.
In particular, you added a function called from one place that took a
Boolean argume
On Tue, Dec 15, 2015 at 7:31 PM, Robert Haas wrote:
>
> On Mon, Dec 14, 2015 at 8:38 AM, Amit Kapila
wrote:
> > set enable_hashjoin=off;
> > set enable_mergejoin=off;
>
> [ ... ]
>
>
> > Now here the point to observe is that non-parallel case uses both less
> > Execution time and Planning time to
On Wed, Dec 16, 2015 at 7:14 PM, Magnus Hagander wrote:
> On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier
> wrote:
>> Interesting. I got just today a bug report that is actually a symptom
>> that people should be careful about: it is possible that
>> pg_stat_replication reports 1/potential for s
On Wed, Dec 16, 2015 at 1:34 AM, Amit Kapila wrote:
> Yes, thats one thing I wanted to know, yet another point which is not
> clear to me about this Async infrastructure is why the current
> infrastructure
> of Parallelism can't be used to achieve the Async benefits of ForeignScan?
Well, all a Fo
Hi, thanks for the review.
> 1) (nitpicking) There seem to be some minor whitespace issues, i.e.
> trailing spaces, empty lines being added/removed, etc.
Fixed, I think
> 2) one of the regression tests started to fail
>
> SELECT '-1e-700'::cube AS cube;
>
> This used to return (0) but n
Hi,
On 12/14/2015 12:51 PM, Simon Riggs wrote:
On 13 December 2015 at 17:28, Alexander Korotkov
mailto:a.korot...@postgrespro.ru>> wrote:
it would be nice to make compression methods pluggable.
Agreed.
My thinking is that this should be combined with work to make use of
the compressed da
Here is a two part v12, which:
part a (refactoring of scripts and their stats):
- fix option checks (-i alone)
- s/repleacable/replaceable/ in doc
- keep small description in doc and help for -S & -N
- fix 2 comments for pg style
- show builtin list if not found
part b (weight)
- check th
On 12/14/2015 01:57 PM, Merlin Moncure wrote:
This may be moot; some testing demonstrated that libedit was not
impacted so it really comes down to having the right readline api call
available. Looking at the code ISTM that libedit resets the terminal
on every prompt.
Did you manage to figure o
On 16 December 2015 at 18:11, Haribabu Kommi
wrote:
> On Tue, Dec 15, 2015 at 8:04 AM, Paul Ramsey
> wrote:
> > But the run dies.
> >
> > NOTICE: SRID value -32897 converted to the officially unknown SRID
> value 0
> > ERROR: Unknown geometry type: 2139062143 - Invalid type
> >
> > From the me
It seems also that it would be a good idea to split the patch into two
parts:
1) Refactor the code so as the existing test scripts are put under the
same umbrella with addScript, adding at the same time the new option
-b.
2) Add the weight facility and its related statistics.
Sigh. The patch &
On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier
wrote:
> On Mon, Dec 14, 2015 at 8:59 AM, Michael Paquier
> wrote:
> > On Mon, Dec 14, 2015 at 1:01 AM, Magnus Hagander
> wrote:
> >> I've applied these two patches now.
> >>
> >> The one that fixes the initialization backpatched to 9.3 which is
On 16 December 2015 at 09:51, Viktor Leis wrote:
> Hi,
>
> We have recently performed an experimental evaluation of PostgreSQL's
> query optimizer. For example, we measured the contributions of
> cardinality estimation and the cost model on the overall query
> performance. You can download the re
Hi,
We have recently performed an experimental evaluation of PostgreSQL's
query optimizer. For example, we measured the contributions of
cardinality estimation and the cost model on the overall query
performance. You can download the resulting paper here:
http://www.vldb.org/pvldb/vol9/p204-leis.p
Updated patch to add this table creation case in regression tests.
PFA patch version V3.
Regards,
Amul Sul
transformCheckConstraints-function-to-overrid-not-valid_V3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On Wed, Dec 16, 2015 at 8:19 AM, Tomas Vondra
wrote:
> Hi,
>
> I've reviewed the patch today, after re-reading the whole discussion.
Thanks for the review.
> The one unsolved issue is what to do with 1e24cf64. My understanding is that
> the current patch still requires reverting of that patch, b
Hello, I think I found a typo in a comment of syncrep.c.
> * acknowledge the commit nor raise ERROR or FATAL. The latter would
> - * lead the client to believe that that the transaction aborted, which
> * is not true: it's already committed locally. The former is no good
The 'that' looks dup
86 matches
Mail list logo
