On Wed, Jul 19, 2017 at 7:45 PM, Thomas Munro
wrote:
> On Thu, Jul 20, 2017 at 7:00 AM, Robert Haas wrote:
>> I think the problem is that the row count estimates for the child
>> joins seem to be totally bogus:
>>
>> -> Hash Semi Join (cost=309300.53..491665.60 ro
;t well-liked, we may
well end up with one behavior for v<10, another behavior for v=10, and
a third behavior for v>10. Better to wait and make the change later
when we have a few more data points.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
-
wise might like to also argue for dropping
> float4 because float8 does all the same stuff better.
I don't think that's the same thing, but given my notorious hatred of
floating point arithmetic, it would also bother me less than you might
think.
--
Robert Haas
EnterpriseDB: http:
to integrate PG into an AD environment
> would be better. It's not my intent to stop this patch but rather to
> point out the issues with LDAP auth that far too frequently are not
> properly understood.
Then it's off-topic for this thread.
--
Robert Haas
EnterpriseDB: http://w
On Wed, Jul 19, 2017 at 2:29 PM, Mark Rofail wrote:
> On Wed, Jul 19, 2017 at 7:28 PM, Robert Haas wrote:
>>
>> Why do we have to solve that limitation?
>
> Since the regress test labled element_foreing_key fails now that I made the
> RI queries utilise @(anyarray, anye
rows
as input is estimated to produce only 1 row of output. I bet the
problem is that the child-join's row count estimate isn't getting
initialized at all, but then something is clamping it to 1 row instead
of 0.
So this looks like a bug in Ashutosh's patch.
--
Robert Haas
Enterpris
On Wed, Jul 19, 2017 at 1:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane wrote:
>>> I'd definitely be on board with just dropping the type altogether despite
>>> Mark's concern.
>
>> Then I vote for that o
easonably efficient. Is anybody going to work on getting that
committed?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, on the other hand, could probably
be made to work, perhaps with some greater or lesser degree of
modification.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Jul 19, 2017 at 2:25 AM, Michael Paquier
wrote:
> Would we want to improve the error handling of such objects?
+1 for such an improvement.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Wed, Jul 19, 2017 at 8:08 AM, Mark Rofail wrote:
> To summarise, the options we have to solve the limitation of the @>(anyarray
> , anyelement) where it produces the following error: operator does not
> exist: integer[] @> smallint
Why do we have to solve that limitation?
tely be on board with just dropping the type altogether despite
> Mark's concern.
Then I vote for that option.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
ld run it for another day with core dumps enabled (try
the "-c" option to pg_ctl) and then pull a backtrace if you get one.
This is a pretty generic script so it's going to be hard to guess
where the problem is otherwise.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
suppose I'm internally assuming that it's
because the people who wrote the code are far more brilliant and
knowledgeable of this area than I could ever be and that doing
anything else would create some kind of awful problem, but maybe
that's not so.
--
Robert Haas
EnterpriseDB: http:
, but that sounds like a neat idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
form in plperl and perl modules incase of
>> Windows but on Linux it remains same in both the modules.
>
> Yipes.
+1 for "yipes". It sounds like we should really try to fix the
underlying problem, rather than just working around the check.
--
Robert Haas
EnterpriseDB:
a #define for the base year. Silently
changing the interpretation of the same data in the core code, though,
seems both far too clever and not clever enough.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pg
On Mon, Jul 10, 2017 at 5:44 PM, Robert Haas wrote:
> The posted patches look OK to me. Barring developments, I will commit
> them on 2017-07-17, or send another update by then.
Committed them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL C
a specific version, and the possibility that someone
will argue for keeping it as a matter of historical interest cannot be
ruled out. In a community where anything at all can be relitigated at
the drop of a hat, making promises about what will happen in the
future is mostly wishful thinking.
--
ical fix to this problem with
minimal chance of breaking anything new, and that seems like the right
kind of fix for July. So I plan to commit what Amit proposed (with a
few grammar corrections).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
ALUE
syntax -- it's really +/- infinity, not a value at all -- but I
haven't got a better proposal and yours at least has the virtue of
perhaps being familiar to those who know about Oracle.
Do you want to own this open item, then?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.c
everything we remove, but it will
always be worded in a certain way. If you're trying to streamline the
process of deprecating features, that's going in the exact wrong
direction.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent v
ing out the lack of future-proof-ness of abstime.
+1 for fixing that, though. Maybe we can find a wording that says in
effect "this module will need to be removed or fixed sometime not too
many years from now; if you care about keeping it around, maybe you
should volunteer to do the necessa
this well enough alone. We're
post-beta2 now, there's no clear consensus on what to do here, and
there will be very little opportunity for users to give us feedback if
we stick a change into an August beta3 before a September final
release.
--
Robert Haas
EnterpriseDB: http://www.enter
to be
true, and this slows things down in cases that anyone cares about, I
think that's going to be a problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
to think it's
an ugly kludge to shove some other kind of value into a TID, anyway.
If we need to store something that's not a TID, I think we should have
a purpose-built mechanism for that, not just hammer on the existing
system until it sorta works.
--
Robert Haas
EnterpriseDB: http://ww
have now, and anything
that really changes the paradigm is off-limits, well, that's not
really interesting enough to justify the work of creating a heap
storage API.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailin
have a
better solution off the top of my head, but I feel slightly nervous.
Apologies again for the slow response - will update again by Monday.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hacke
I'm not
generally very excited about changing things after beta2, which is
where are, but if this is a security issue then we might need to hold
our nose and go ahead. I'm against it if it's likely to cause
real-world connectivity problems, though.
--
Robert Haas
EnterpriseDB: ht
locations, or visca versa. But count
me as +0 for widening them to 64-bits.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ust
tell the server - via this protocol message - to nail down
session_authorization or application_name or appuser.thunk to some
value of your choice, and it's invulnerable to SQL injection
thereafter.
Whaddaya think?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
t;, we wouldn't need a separate flag for marking a table
> as having partitions.
I think that is false. Whether something is partitioned and whether
it is a partition are independent concerns.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
of these changes. I think this patch would
benefit from being accompanied by several paragraphs of explanation
outlining the rationale for each part of the patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql
may
> discover new open items at any time, and I want to plan to get them all fixed
> well in advance of shipping v10. Consequently, I will appreciate your efforts
> toward speedy resolution. Thanks.
The posted patches look OK to me. Barring developments, I will commit
them on 2017
On Fri, Jul 7, 2017 at 11:36 PM, Amit Kapila wrote:
> I think we should do that as a separate patch (I can write the same as
> well) because that is not new behavior introduced by this patch, ...
True, although maybe hash indexes are the only way that happens today?
--
Robert Haas
Enterp
ReadBuffer_common(smgr, RELPERSISTENCE_PERMANENT, forkNum, blockNum,
> mode, strategy,
> &hit);
>
> This surely works since BufferAlloc recognizes INIT_FORK. But
> some adjustment may be needed around here.
Yeah, it should probably mention tha
some
other committer is welcome to do so if they feel confident in the fix.
I will update again by July 17th.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
hentication. So unless I'm misunderstanding, the solution
you are proposing figures to have a very limited shelf life.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 7, 2017 at 8:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> I don't have a strong view on whether partitions should be hidden by
>> default, although I lean slightly against it (say, -0.25). But if we
>> do decide to hide them by default, then I definit
.
Is it just that their row locking is way faster than ours?
I'm more curious about why we're performing badly than I am about a
general-purpose random_zipfian function. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
25). But if we
do decide to hide them by default, then I definitely want an
easy-to-use modifier that overrides that behavior, like being able to
type \d! or whatever to have them included after all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
d likely have at least a
minor performance cost.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rying had likely
> changed
> enough for the performance to change. That duped me into thinking I had
> found a work-around. I can no longer reproduce any performance improvement
> in this manner.
Also note that temporary tables are yet another thing that doesn't
work
12gpz8dxhcm9_ft1y-0fvzxi9p...@mail.gmail.com
I tend to favor that approach myself, although one point in favor of
your suggestion is that adding another flag to pg_dumpall is a heck of
a lot less work to get to some kind of solution to this issue.
--
Robert Haas
EnterpriseDB: http://www.enterprise
ss
> again? The state machine may not sound simple with this proposal but helps
> bringing down total time taken for the login.
Nothing in that proposal involved an extra connection setup process;
if that's not clear, you might want to reread it.
--
Robert Haas
EnterpriseDB: http://www.e
On Fri, Jun 30, 2017 at 4:20 PM, Robert Haas wrote:
> I don't think the approach of building a hash table to figure out
> which result rels have already been created is a good one. That too
> feels like something that the planner should be figuring out and the
> execut
ure out
which result rels have already been created is a good one. That too
feels like something that the planner should be figuring out and the
executor should just be implementing what the planner decided. I
haven't figured out exactly how that should work yet, but it seems
like it ought to
t;developed on NetBSD. The
>>libedit library is
>>
>
> I don't think this was a typo.
I agree.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jun 28, 2017 at 5:11 AM, Masahiko Sawada wrote:
> Attached patch for $subject.
> A period is missing at the end of sentence.
Seems reasonable. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers m
on attnum < 0 as a proxy for whether the column should be displayed.
BTW, if we get either of these things, can I vote for, as a follow-on
patch, changing OID columns to be displayed by default, at least in
system catalogs? I don't think that having the primary keys of our
system catal
plaint; conversely,
if the connection string had require_whizzbang=2, and the server is
too old to support that, then the client can decide to bail out when
it receives the ServerProtocolVersion message.
Still just thinking out loud here. Thoughts?
--
Robert Haas
EnterpriseDB: http://www.en
On Wed, Jun 28, 2017 at 1:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here's my proposal:
>
>> - If the server receives a StartupMessage for v3.x where x > the
>> version it knows, instead of just slamming the connection shut, it
>> responds
t we have today. I'm not really keen on trying to
introduce a v4 protocol any time soon, but I really like the idea of
having a reasonably low-pain way to introduce a v3.1 that adds modest
new capabilities.
Thoughts, better ideas?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
artition by range (a
text_ops, b text_pattern_ops);
CREATE TABLE
I don't really see anybody wanting to do that, but I don't really see
anyone wanting to do with an index either.
My inclination is to reject this patch as not solving any actual problem.
--
Robert Haas
EnterpriseDB: http://www.
etime, you'll want to dump, so that after
the next restart you have something to preload. But this design would
allow that.
That's all I have time for today - hope it helps.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
unpinned objects with OIDs in the hand-assigned range,
> along the lines of this prototype code:
I don't have specific thoughts, but I like the general idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Wed, Jun 21, 2017 at 8:47 PM, Amit Langote
wrote:
> It's the comma inside the error message that suggests to me that it's a
> style that I haven't seen elsewhere in the backend code.
Exactly. Avoid that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
cluding that in the
> comments for that function.
Committed with a slight adjustment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
into GENERICTEXTS.
>
> =
>
> I don't attach the *second* patch since it's too large for the
> trivality and can be made by the following steps.
>
> $ cd src/backend/utils/mb/Unicode
> $ git rm *.txt
> $ git commit
I think you are right about all of this, alth
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fix it by putting the check into proc_exit itself.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s defined in contrib/postgres_fdw/deparse.c, we should put that
> declaration in the section of deparse.c in the header file. Attached is a
> patch for that.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers m
[2].
I'm no longer very sure fixing this is a very simple thing to do,
partly because of the use of lseek to get the file size which you note
above, and partly because of the possibility that this may, for
example, break read-ahead, as Tom worried about previously[3]. But I
think dismissing
028b99795
> Author: Peter Eisentraut
> Date: Thu Mar 16 18:54:28 2017 -0400
>
> psql: Add completion for \help DROP|ALTER
>
> PFA patch to fix the same.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent v
ace later
on in the planner. If the logic as-written would work correctly in
that case now, I can't see why we should turn it into an assertion
failure instead. This isn't really costing us anything, is it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgr
On Wed, Mar 29, 2017 at 3:18 AM, Ashutosh Bapat
wrote:
>> Update patch attached.
>
> Looks good to me.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
rary
order at that point in the syntax. I'm not sure whether that's
something we'll ever actually need, or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
te some extra work for whoever has to do those merges, but if
that's what the community thinks is best, we will of course manage.
It's not *that* bad.
It would be slightly less annoying for us, I think, if the reindent
were done immediately after a minor-release rather than at some othe
can be
> implemented using #1.
I don't think anybody's arguing with that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gine that we can
pick *either* the parent's attribute ordering *or* that of the first
child and nothing will be different - the attribute numbers inside the
returning lists and WCOs we create have got to get used somehow, so
surely it matters which attribute numbers we use, doesn't it?
--
ctually I was going for disallowing BR update trigger to
> initiate tuple routing, as I described above.
I know that! But as I said before, they requires evaluating every
partition key constraint twice per tuple, which seems very expensive.
I'm very doubtful that's a good ap
I'm more interested in #1 than in #3, and more interested in #3 than
#2, but other people may have different priorities.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fferent machines is going to
be tough.
But I agree with your other concerns. I think the problem is real,
but I'm not sure that this is the best solution. On the other hand,
I'm also not entirely sure I understand the proposal yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.
application-in-the-world territory.
> P.S: I am looking for initial feedback on this idea and can provide more
> design details if needed.
I think you need to build a more compelling case for why this would be
useful, why application_name isn't the right answer, and how we avoid
forcing
cancel_backend for autovacuum launcher,
> it causes the following error. I'll report the detail in another thread.
>
> ERROR: can't attach the same segment more than once
I think that's a bug.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
nt here is that if we have a partitioned table with a bunch of
descendent tables, the non-leaf partitions are never actually scanned;
there's no file on disk to scan. Despite the lack of a scan, we still
need to arrange for those relations to be locked.
--
Robert Haas
EnterpriseDB: http:/
.
>
> Yep, it's more appropriate to use
> ModifyTableState->rootResultRelationInfo->ri_RelationDesc somehow. That
> is, if answer to the question I raised above is positive.
The questions appear to me to be independent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rind. It seems to be really easy to
miss these uninitialized access problems during code review.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
db4e912592bcc; 2011).
Did that, possibly, remove the last way in which a simple expression
could be could become non-simple? If so, between that and the new
hasTargetSRFs test, it might now be impossible for
exec_simple_check_node() to fail.
--
Robert Haas
EnterpriseDB: http://www.enterprise
On Tue, Jun 20, 2017 at 3:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 19, 2017 at 9:57 PM, Tom Lane wrote:
>>> Hm, patch looks okay, but while eyeballing it I started to wonder
>>> why in the world is pg_get_publication_tables marked prosecdef?
>&
space before the comma looks strange.
Also, please make a habit of checking patches for whitespace errors
using git diff --check.
[rhaas pgsql]$ git diff --check
src/backend/executor/nodeModifyTable.c:384: indent with spaces.
+tuple, &slot);
src/backend/executor/nodeM
7;s trying to say in the first place.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
>
> Hm, patch looks okay, but while eyeballing it I started to wonder
> why in the world is pg_get_publication_tables marked prosecdef?
> If that has any consequences at all, they're probably bad.
> There are exactly no other built-in functions that have that set.
Should we add
On Mon, Jun 19, 2017 at 3:47 PM, Peter Geoghegan wrote:
> On Mon, Jun 19, 2017 at 12:19 PM, Robert Haas wrote:
>> I don't have a specific use case in mind. However, datumCopy() is
>> sure to be a lot faster when typByVal is true, and see also the
>> docum
On Sun, Jun 18, 2017 at 6:59 PM, Andrew Gierth
wrote:
> (Any preferences for whether it should be one commit or 3 separate ones?)
If I were doing it, I would commit them separately.
But I'm not doing it, so I won't complain about what you decide to do.
--
Robert Haas
Enter
hroughout the tree and
different attributes might be needed at different levels. Moreover,
in most cases, the mappings are going to end up being no-ops because
the column order will be the same, so it's probably not worth
complicating the code to try to avoid a double conversion that usually
wo
On Mon, Jun 19, 2017 at 1:10 PM, Peter Geoghegan wrote:
> On Mon, Jun 19, 2017 at 10:00 AM, Robert Haas wrote:
>> I've never been very happy with the performance of numeric, so I guess
>> I'm a bit more optimistic about the chances of doing better. Aside
>> from
e 4-byte version
can't represent that quantity at all. That combination of facts seems
like a big problem to me. A decimal representation that can't handle
more than 7 digits is going to unsuitable for many applications, and
being bigger than our existing numeric on disk for many
commonly
On Mon, Jun 19, 2017 at 12:30 PM, Robert Haas wrote:
> On Thu, Jun 15, 2017 at 7:51 PM, Alvaro Herrera
> wrote:
>> I thought we called it "incremental development". From the opposite
>> point of view, would you say we should ban use of passphrase-protected
>>
use for data-at-rest encryption myself, but I wouldn't stop
> development just because the initial design proposal doesn't include
> top-notch key management.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;t imply
> that this trigger guarantees to suppress every no-op update.
That doesn't sound like a very plausible argument to me. I don't
think that a proposal to add a function named
sometimes_suppress_redundant_updates_trigger() would've attracted many
votes.
--
Robert
at does not depend on anybody else's code
under some other license, or we could wait and see if they become more
mainstream.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
ld be better to have it separate.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jun 17, 2017 at 11:58 PM, Thomas Munro
wrote:
> On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas wrote:
>> On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro
>> wrote:
>>> On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas wrote:
>>>> I feel like these would log
On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro
wrote:
> On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas wrote:
>> On Thu, Jun 15, 2017 at 10:27 PM, Thomas Munro
>> wrote:
>>> 1. They are fixed size, and DECFLOAT(9) [= 32 bit] and DECFLOAT(17)
>>> [= 64 bit] could
On Fri, Jun 16, 2017 at 10:51 AM, Tom Lane wrote:
> So I'm back to the position that we ought to stick the indent
> code under src/tools/ in our main repo. Is anyone really
> seriously against that?
Is it under the same license as everything else?
--
Robert Haas
Ente
ly just be different types, like int4
and int8 are. We don't have integer(9) and integer(18).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On Thu, Jun 15, 2017 at 5:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 15, 2017 at 5:06 PM, Tom Lane wrote:
>>> ... nodeGather cannot deem the query done until it's seen EOF on
>>> each tuple queue, which it cannot see until each worker has attach
On Thu, Jun 15, 2017 at 5:06 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> I think you're right. So here's a theory:
>
>>> 1. The ERROR mapping the DSM segment is just a case of the worker the
>>> losing a race, and isn't a bug.
andy to be able to run
this without arguments (or just with -z) and have it process all the
WAL files that you've got on hand.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
801 - 900 of 21742 matches
Mail list logo
