traints() and have it validate all remaining checks.
28. For table WITH OIDs, the OID should probably follow the new tuple
for partition-key-UPDATEs.
CREATE TABLE p (a BOOL NOT NULL, b INT NOT NULL) PARTITION BY LIST (a)
WITH OIDS;
CREATE TABLE P_true PARTITION OF p FOR VALUES IN('t'
A patch to fix this is attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
event_trigger_statistics_doc.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
gt;> (BITS_PER_BITMAPWORD - (BITNUM(upper) - 1));
> =
No objections here for making bms_add_range() perform better, but this
is not going to work when lwordnum == uwordnum. You'd need to special
case that. I didn't think it was worth the trouble, but maybe it is...
I assume
On 7 November 2017 at 01:52, David Rowley wrote:
> Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
Hi Amit,
I had another look over this today. Apologies if any of the review seems petty.
Here goes:
1. If test seems to be testing for a child that's
On 7 November 2017 at 01:52, David Rowley wrote:
> Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
I have a little more review to share:
1. Missing "in" in comment. Should be "mentioned in"
* get_append_rel_partitions
* Return the list of
the fix to make the new pruning
> code handle Boolean partitioning.
Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13)
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pg
resql.org/gitweb/?p=postgresql.git;a=commit;h=d4c3a156cb46dcd1f9f97a8011bd94c544079bb5
[2]
https://www.postgresql.org/message-id/flat/CAKJS1f9q0j3BgMUsDbtf9%3DecfVLnqvkYB44MXj0gpVuamcN8Xw%40mail.gmail.com#CAKJS1f9q0j3BgMUsDbtf9=ecfvlnqvkyb44mxj0gpvuamcn...@mail.gmail.com
--
David Rowley
On 6 November 2017 at 17:30, Amit Langote wrote:
> On 2017/11/03 13:32, David Rowley wrote:
>> On 31 October 2017 at 21:43, Amit Langote
>> wrote:
>> 1. This comment seem wrong.
>>
>> /*
>> * Since the clauses in rel->baserestrictinfo should all
owed too. This works slightly differently.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3 November 2017 at 17:32, David Rowley wrote:
> 2. This code is way more complex than it needs to be.
>
> if (num_parts > 0)
> {
> int j;
>
> all_indexes = (int *) palloc(num_parts * sizeof(int));
> j = 0;
> if (min_part_idx >= 0 && max_part
On 3 November 2017 at 03:26, Craig Ringer wrote:
> On 2 November 2017 at 22:22, David Rowley
> wrote:
>> Maybe, but the new implementation is not going to do well with places
>> where we perform lcons(). Probably many of those places could be
>> changed to lappend(),
PARTITION_MAX_KEYS * sizeof(NullTestType *));
should be PARTITION_MAX_KEYS * sizeof(NullTestType). It might have
worked on your machine if you're compiling as 32 bit.
I'll continue on with the review in the next few days.
--
David Rowley http://www.2ndQuadrant.com/
ab13bf. Can you send patches rebased on current master?
Thanks
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On 3 November 2017 at 03:27, Stephen Frost wrote:
> * David Rowley (david.row...@2ndquadrant.com) wrote:
>> We could get around a few of these problems if Lists were implemented
>> internally as arrays, however, arrays are pretty bad if we want to
>> delete an item out the m
On 3 November 2017 at 03:38, Tom Lane wrote:
> David Rowley writes:
>> On 3 November 2017 at 03:17, Tom Lane wrote:
>>> We've jacked up the List API and driven a new implementation underneath
>>> once before. Maybe it's time to do that again.
>
>>
of those places could be
changed to lappend(), but I bet there's plenty that need prepend.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
xecutor)
Comments on the design are welcome, but I was too late to the
commitfest, so there are other priorities. However, if you have a
strong opinion, feel free to voice it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
00
andling.
A patch to do this is attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
0001-Support-removing-LEFT-JOINs-with-DISTINCT-GROUP-BY.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsq
On 30 October 2017 at 22:44, Andres Freund wrote:
> On 2017-10-30 22:39:01 +1300, David Rowley wrote:
>> Today I was thinking, to get around that issue, we might be able to
>> generate another thin wrapper around elog_start() and mark that as
>> __attribute__((cold)) and fud
On 30 October 2017 at 22:34, Andres Freund wrote:
> Hi,
>
> On 2015-12-20 02:49:13 +1300, David Rowley wrote:
>> Alternatively, if there was some way to mark the path as cold from within
>> the path, rather than from the if() condition before the path, then we
>> could
| | | plain | |
b | integer | | | | plain | |
Partition key: RANGE (a)
Partitions: ab_p1 FOR VALUES FROM (1) TO (1),
ab_p2 FOR VALUES FROM (10000) TO (2)
--
David Rowley http:/
On 26 October 2017 at 23:42, Antonin Houska wrote:
> David Rowley wrote:
>
>> Method 1:
>>
>> In set_append_rel_size() detect when just a single subpath would be
>> added to the Append path.
>
> I spent some time reviewing the partition-wise join patch during
On 26 October 2017 at 23:30, Robert Haas wrote:
> On Wed, Oct 25, 2017 at 11:59 PM, David Rowley
> wrote:
>> As of today, because we include this needless [Merge]Append node, we
>> cannot parallelise scans below the Append.
>
> Without disputing your general notion th
which
would be much cleaner.
[1]
https://www.postgresql.org/message-id/CAKJS1f9UXdk6ZYyqbJnjFO9a9hyHKGW7B%3DZRh-rxy9qxfPA5Gw%40mail.gmail.com
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing l
A small patch to fix these is attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
allpath_typos_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 15 October 2017 at 06:49, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 4:49 PM, David Rowley
> wrote:
>> tps = 8282.481310 (including connections establishing)
>> tps = 8282.750821 (excluding connections establishing)
>
> vs.
>
>> tps = 8520.822410 (including
ust speed up the planner. Perhaps I missed some? It
looks like there's plenty we could do in there, just nobody seems
interested enough to go and do it, everyone who cares about
performance is too busy trying to make execution run faster.
--
David Rowley http://www.2ndQuadran
On 14 October 2017 at 09:04, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 11:03 PM, David Rowley
> wrote:
>> -- Unpatched
>> Planning time: 0.184 ms
>> Execution time: 105.878 ms
>>
>> -- Patched
>> Planning time: 2.175 ms
>> Execution time: 1
I don't really think the DEFAULT_APPEND_COST_FACTOR adds much. it
means very little by itself. It also seems that most of the other cost
functions just use the magic number.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
On 13 October 2017 at 12:41, Tom Lane wrote:
> David Rowley writes:
>> If the user defines their normal aggregate as not safe for merging,
>> then surely it'll not be suitable to be used as a window function
>> either, since the final function will also be called t
f the user defines their normal aggregate as not safe for merging,
then surely it'll not be suitable to be used as a window function
either, since the final function will also be called there multiple
times per state.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL
On 13 October 2017 at 04:56, Alvaro Herrera wrote:
> I pushed your original fix.
Thanks for committing
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-
SELECTs too.
I had imagined this would be some backend local cache that saved MRU
plans up to some size of memory defined by a GUC, where 0 would
disable the feature. I never got any further than those thoughts.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Deve
your code assumed the OpExpr was a Var.
The reason Tomas coded it the way it was coded is due to the fact that
there's already code that works exactly the same way in
clauselist_selectivity(). Personally, I don't particularly like that
code, but I'd rather not invent a n
-
2.400209476818
(1 row)
Maybe it's worth trying with different row counts to see if the
additional cost is consistent, but it's probably not worth being too
critical here.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
Removed by Filter: 333300
Planning time: 2.175 ms
Execution time: 106.326 ms
(8 rows)
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
allow_relabelled_vars_in_dependency_stats.patch
Description: Binary data
--
Sent via pgsq
comment in create_append_path() which claims the zero cost is a bit
optimistic.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On 9 October 2017 at 17:41, David Rowley wrote:
> Thoughts?
Actually, I was a little inconsistent with my List NULL/NIL checks in
that last one.
I've attached an updated patch.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
t that as relations
without unique indexes are pretty uncommon (at least in my world).
Thoughts?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
remove_left_join_distinct.patch
Description: Binary data
--
Sent via
and finding performance is not quite
what they need. It's a bit sad that often the people with the loudest
voices are always so fast to stomp on the ideas for improvements. It
would be much nicer if you'd at least wait for benchmarks before
shooting.
--
David Rowley h
iorated to some degree, but JITing obviously isn't always going to
> be a win.
It's pretty exciting to see thing being worked on.
I've not looked at the code, but I'm thinking, could you not just JIT
if the total cost of the plan is estimated to be > X ? Where
e of that function
is not so pretty and that would likely tidy it up a bit. The matching
partition indexes could be returned as a Bitmapset, yet, I don't
really see any code which handles adding the NULL and DEFAULT
partition in get_rel_partitions() either, maybe I've just not looked
hard
it;h=9140cf826
Yeah, I see 0001 conflicts with that. I'm going to set this to waiting
on author while you're busy rebasing this.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-h
this being a bug.
The attached fixes.
(CC'd -hackers since we're starting to discuss code changes. Further
discussion which includes -hackers should drop the general list)
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &a
x27;s not fully cooked yet though.
I'm interested in seeing improvements in this area, so I've put my
name down to review this.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql
would see some resistance,
so won't have time to look at this soon.
If the possibility of this increasing planning time in corner cases is
going to be a problem, then it might be best to return this with
feedback for now and I'll resubmit if I get time later in the cycle.
--
Da
this
and I don't think anyone was in favour of queries randomly working
sometimes.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
cleanup too.
I'll feel better once pademelon goes green again. From looking at the
latest failure on it, it appears that your swapping of
pg_atomic_write_u64 for pg_atomic_init_u64 should fix this. My
apologies for that mistake.
--
David Rowley http://www.2ndQuadrant.
On 16 August 2017 at 15:38, Peter Eisentraut
wrote:
> committed
Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
ith or without the FK. But in some quick testing I could not
> produce a counterexample proving that that heuristic is helpful;
> so for now let's can it.
>
> Thanks, and sorry again for the delay.
Many thanks for taking the time on this.
--
David Rowley http://
". A nested loop unique join is costed more
cheaply than a non-unique one since we can skip to the next outer
tuple once we've matched the current outer tuple to an inner tuple. In
theory that's half as many comparisons for a non-parameterised nested
loop.
--
David Rowl
to generating a plan that'll blow up like this. Is this a
realistic enough one to bother accounting for? Did it come from a real
world case? else, how did you stumble upon it?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
On 22 May 2017 at 16:10, David Rowley wrote:
> I also just noticed that I don't think I've got ANTI join cases
> correct in the patch I sent. I'll look at that now.
I've attached an updated patch.
This one is much less invasive than my original attempt.
There are tw
27;s version of clauselist_selectivity()
will ignore these join conditions, so nothing can be done to assist
the underestmations by adding extended stats yet.
I also just noticed that I don't think I've got ANTI join cases
correct in the patch I sent. I'll look at that now.
--
On 18 May 2017 at 20:28, David Rowley wrote:
> A vastly simplified example case is:
>
> create table fkest (a int, b int, c int unique, primary key(a,b));
> create table fkest1 (a int, b int, primary key(a,b));
>
> insert into fkest select x/10,x%10, x from generate_Series(1,400
go and see if they can Not because I'm super confident,
more just because I want this to be correct.
Thoughts?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
0001-Minimal-fix-for-foreign-key-join-estimations.patch
Des
something around this in [1].
[1]
https://www.postgresql.org/message-id/CAKJS1f_jRki1PQ4X-9UGKa-wnBhECQLnrxCX5haQzu4SDR_r2Q%40mail.gmail.com
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent vi
m cte WHERE cte.value > 5;
We'd be certain to receive complaints from disgruntled users about
"Why is this not inlined when I specified INLINE?"
#2 does not suffer from that.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
I would
> personally consider the use of a variable, but not here.
Any more thoughts on what is acceptable for fixing this? beta1 is
looming and it seems a bit messy to be shipping that with these
warnings, however harmless they are.
--
David Rowley http://www.2ndQuadrant.
#x27;d want to scan a whole 1GB extent per worker.
I did post a patch to have heap_parallelscan_nextpage() use atomics
instead of locking over in [1], but I think doing atomics there does
not rule out also adding batching later. In fact, I think it
structures things so batching would
nce used for benchmarking! I'm glad
we're all using a couple more rows these days.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
e work.
[1]
https://www.postgresql.org/message-id/CAKJS1f-XhfQ2-%3D85wgYo5b3WtEs%3Dys%3D2Rsq%3DNuvnmaV4ZsM1XQ%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/20170505023646.3uhnmf2hbwtm63lc%40alap3.anarazel.de
--
David Rowley http://www.2ndQuadrant.com/
Postg
he docs. If anything that'll buy us a bit more wiggle room to
change this in v11.
I've attached a proposed patch.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
doc_caution_about_cte_changes_in_the_future
lower by doing it that way.
I didn't manage to think of a way to get around the wrapping the
position back to 0 when synch-scans are involved.
i.e
parallel_scan->phs_cblock++;
if (parallel_scan->phs_cblock >= scan->rs_nblocks)
parallel_scan->phs_cblock = 0;
--
David R
On 3 May 2017 at 07:13, Robert Haas wrote:
> Multiple people (including David Rowley
> as well as folks here at EnterpriseDB) have demonstrated that for
> certain queries, we can actually use a lot more workers and everything
> works great. The problem is that for other queries, us
On 5 May 2017 at 13:37, Andres Freund wrote:
> On 2017-05-02 15:13:58 -0400, Robert Haas wrote:
>> Multiple people (including David Rowley
>> as well as folks here at EnterpriseDB) have demonstrated that for
>> certain queries, we can actually use a lot more workers and ever
batches too big as we might end up
having to wait on slow workers at the end of a scan.
Anyway. I don't want to hi-jack this thread with discussions on this.
I just wanted to mark that I plan to work on this in order to avoid
any repeat developments or analysis. I'll probably start a new thre
On 2 May 2017 at 00:10, David Rowley wrote:
> On 20 April 2017 at 07:29, Euler Taveira wrote:
>> 2017-04-19 1:32 GMT-03:00 Michael Paquier :
>>>
>>> I vote for "location" -> "lsn". I would expect complains about the
>>> current in
aimed return type of
pg_logical_slot_peek_changes.location was text, when it was pg_lsn
(maybe apply separately?)
7. Change some places in the func.sgml where it was referring to the
lsn as a "position" rather than "location". (We want consistency here)
Is this touching all
x27;d be voting for
minimal patch if this was for a minor version release fix, but we're
not even in beta yet for v10. The original patch was intended to fix
cases like this, although I'd failed to realise this particular case.
--
David Rowley http://www.2ndQuadrant.com/
o fix the issue.
I don't know yet if that's the correct fix. It's pretty late 'round
this side to be thinking too hard about it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent vi
On 29 April 2017 at 00:45, Alexander Korotkov wrote:
> On default config, after loading example.sql.bz2 and VACUUM ANALYZE, query
> result is OK.
Hi,
Did you mean to attach this?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Tr
dgment and add to the next 'fest.
Thanks
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 27 April 2017 at 01:31, Peter Eisentraut
wrote:
> committed
Great. Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
ng to 9.6, I came up with the attached reduced version.
> Since we don't have add_foreign_grouping_paths() in 9.6, we can omit the
> refactoring and keep the changes much simpler. Does that make sense?
That makes sense to me. It fixes the reported issue and is less
invasive than the pg10 patch.
--
On 25 April 2017 at 02:15, Tom Lane wrote:
> David Rowley writes:
>> The attached small patched fixes an incorrect usage of an error code
>> in the extended stats code.
>
> Hmm, looks like all of that could do with an editorial pass (e.g.,
> "duplicity" does
nt when multiplying selectivity estimations for multiple columns.
Unsure how best to trim that down to something short enough for the
release notes.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgs
The attached small patched fixes an incorrect usage of an error code
in the extended stats code.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ext_stats_duplicate_column_errorcode_fix.patch
Description: Binary
e
to CREATE INDEX
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t you're
proposing and why it's not any good.
[1]
https://www.postgresql.org/message-id/cakjs1f9hmet+7adiceau8heompob5pkkcvyzliezje3dvut...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAEZATCUtGR+U5+QTwjHhe9rLG2nguEysHQ5NaqcK=vbj78v...@mail.gmail.com
--
David Rowley
been added in [1]
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a71f10189dc10a2fe422158a2c9409e0f77c6b9e
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsq
.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
appendStringInfo_fixes.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 19 April 2017 at 15:31, Tom Lane wrote:
> David Rowley writes:
>> OK, so I've read over this thread again and I think it's time to
>> summarise the votes:
>> ...
>> In favour of "location" -> "lsn": Stephen, David Steel,
>> In
"location" seems to be winning
Is that enough to proceed?
Anyone else?
The patch to do this should likely also include a regression test to
ensure nothing new creeps in which breaks the new standard.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Deve
inal patch and added to it a bit,
but credits don't seem to reflect that. It's not the end of the world
but just wanted to note that.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers
On 18 April 2017 at 09:01, Alvaro Herrera wrote:
> David Rowley wrote:
>> While reviewing extended stats I noticed that it was possible to
>> create extended stats on many object types, including sequences. I
>> mentioned that this should be disallowed. Statistics were then
y depend on the
shippable_extensions.
Apart from that, it all looks fine to me.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
ind is better.
A patch which changes this is attached
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ext_stats_rename_staenabled.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On 12 April 2017 at 21:45, Ashutosh Bapat
wrote:
> On Wed, Apr 12, 2017 at 12:18 PM, David Rowley
> wrote:
>> On 10 March 2017 at 17:33, Ashutosh Bapat
>> wrote:
>>> Yes and I also forgot to update the function prologue to refer to the
>>> fpinfo_o/i
should I?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
value it would add. Maybe we need to discuss this, but in the
meantime, I've attached a patch which just removes the view completely
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
drop_pg_stats_ext_view.pat
allow anything ANALYZE is allowed on.
The attached does this.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ext_stats_on_analyzable_objects.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (p
log | pg_last_wal_replay_location| pg_lsn |
| normal
pg_catalog | pg_wal_location_diff | numeric |
pg_lsn, pg_lsn | normal
(6 rows)
Opinions?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
S
s used after being assigned, whereas,
some other compilers might see the variable as uselessly assigned.
At the moment there are no other warnings from MSVC since all the
other places the variable gets assigned a value in some code path.
--
David Rowley http://www.2ndQuadrant.com/
Po
eric way of solving this
which I'd like to take care of in PG11.
Many thanks for your reviews and suggestions on this patch, it's much
appreciated.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via
On 8 April 2017 at 14:23, Tom Lane wrote:
> David Rowley writes:
> [ unique_joins_2017-04-07b.patch ]
>
> It turned out that this patch wasn't as close to committable as I'd
> thought, but after a full day of whacking at it, I got to a place
> where I thought it was O
idth=4) (actual
time=0.903..0.903 rows=0 loops=1)
Filter: ((value >= 101) AND (value <= '-1'::integer))
Rows Removed by Filter: 10000
Planning time: 0.162 ms
Execution time: 0.925 ms
(5 rows)
Which comes from the 1 * 0.005 selectivity estimate from tuples *
DEFAULT_RAN
gt; Therefore I propose changing the defaults in pg_regress.c.
You mean people actually use those diffs? I've never done anything
apart from using . That way I can
reject and accept the changes as I wish, just by kicking the results
over to the expected results, or not, if there's a genui
On 7 April 2017 at 13:41, Tom Lane wrote:
> David Rowley writes:
>> On 7 April 2017 at 11:47, Tom Lane wrote:
>>> What I'm on about is that you can't do the early advance to the
>>> next outer tuple unless you're sure that all the quals that were
>
On 7 April 2017 at 11:47, Tom Lane wrote:
> David Rowley writes:
>> On 7 April 2017 at 07:26, Tom Lane wrote:
>>> I'm looking through this, and I'm failing to see where it deals with
>>> the problem we discussed last time, namely that you can't apply th
1 - 100 of 915 matches
Mail list logo
