(like we do when we fill
vacrelstats-dead_tuples.
But like I said above, I think this is already making a mountain out of a
mole-hill, until we have evidence there's a real problem.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
On 11/7/14, 8:21 PM, Robert Haas wrote:
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem right now is there's no way to actually obtain evidence that
this is (or isn't) something to worry about, because we just silently skip
pages. If we had any kind
On 11/10/14, 11:28 AM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 11/7/14, 8:21 PM, Robert Haas wrote:
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem right now is there's no way to actually obtain evidence that
this is (or isn't) something to worry about
.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/10/14, 12:56 PM, Andres Freund wrote:
On 2014-11-10 12:37:29 -0600, Jim Nasby wrote:
On 11/10/14, 12:15 PM, Andres Freund wrote:
If what we want is to quantify the extent of the issue, would it be more
convenient to save counters to pgstat? Vacuum already sends pgstat
messages, so
cases, but now
some folks are saying that everyone should just use streaming rep and be done with it. :P
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
(which should be infrequent).
I believe the low normal space usage is just an indication that most databases
don't use many MultiXacts.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 11/11/14, 2:03 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 11/10/14, 7:40 AM, Alvaro Herrera wrote:
Ah, right. So AFAIK we don't need to keep anything older than
RecentXmin or something like that -- which is not too old. If I recall
correctly Josh Berkus was saying in a thread about
On 11/11/14, 2:01 AM, Andres Freund wrote:
On 2014-11-10 19:36:18 -0600, Jim Nasby wrote:
On 11/10/14, 12:56 PM, Andres Freund wrote:
On 2014-11-10 12:37:29 -0600, Jim Nasby wrote:
On 11/10/14, 12:15 PM, Andres Freund wrote:
If what we want is to quantify the extent of the issue, would
be more appropriate?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
into it? Presumably that means we'd have to keep the page
locked until the image is written...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
multi-key partitions with
something like an anyarray. Perhaps that's OK as a first pass, but I expect
it'll be one of the next things folks ask for.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list
is a lot more limited than for an XID,
so it's probably pretty safe setting that to zero.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
then we shouldn't have to *any* re-validate when we load? (Though, we'd have to
be careful of that with CHECK because that can call user code...)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list
.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of statement_timeout for transactions;
the ability to abort a transaction if it runs for too long.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
for simple sanity checking because it was much nicer than typeing IF THEN RAISE
ERROR END IF.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
use another PL or it's just syntax sugar improve things for
our users.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
haven't been touched since the last time you calculated then you're
don't need to recalc.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
we'd need to prevent anyone from copying a database while being
vacuumed, as well as preventing anyone from changing datcanconnect while the
vacuum is running.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers
impacts a lot of reporting
scenarios.
I fully agree that it's impractical to completely restrict this case, but
something akin to FORCE seems reasonable. If nothing else, I'd think we should
at least issue a warning if someone does something that might affect index
viability.
--
Jim Nasby, Data
Is there any way to determine the typemod of the source data for a cast?
Perhaps a modification on get_call_expr_argtype(), though I'd hate to put that
in an extension...
BTW, it'd be nice if we better emphasized that the typmod passed to a cast
function is for the destination... :/
--
Jim
doesn't get cancelled anymore.
Opinions?
What do you mean by never succeed? Is it skipping a large number of pages?
Might re-trying the locks within the same vacuum help, or are the user locks too
persistent?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble
On 11/10/14, 7:52 PM, Tom Lane wrote:
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether there is really an issue.
Attached is a patch that does this.
--
Jim Nasby, Data Architect, Blue
On 12/1/14, 11:57 AM, Andres Freund wrote:
On 2014-11-30 20:46:51 -0600, Jim Nasby wrote:
On 11/10/14, 7:52 PM, Tom Lane wrote:
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether
There doesn't seem to be documentation on *= (or search isn't finding it). Is
this intentional?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
point.
Now that's not a bad idea. This would basically mean just saving a block number
in pg_class after every intermediate index clean and then setting that back to
zero when we're done with that relation, right?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
) is that you could leave holes in
your partitioning map. Note that in the multi-key case we could still have a
record of rangetypes.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
for this purpose maybe?
Why not? RAID arrays typically use stripe sizes in the 128-256k range, which
means only 16 or 32 sequences per stripe.
It still might make sense to allow controlling what tablespace a sequence is
in, but IMHO the default should just be pg_default.
--
Jim Nasby, Data Architect
: insert into t (col, col) values ((42, 43), (44, 43));
^
Isn't this a bit odd?
Yes, and sounds like a good way to create bugs... my vote would be to fix this.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
instead of at plan time? That would allow us to dynamically
scale parallelism based on system load. If we don't even consider parallelism
until we've pulled some number of tuples/pages from a relation, this would also
eliminate all parallel overhead on small relations.
--
Jim Nasby, Data
would
need to be a dumb varlena that stores the composite HeapTupleHeader.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 12/5/14, 1:22 PM, Jim Nasby wrote:
On 12/5/14, 3:42 AM, Amit Langote wrote:
I think you are right. I think in this case we need something similar
to column pg_index.indexprs which is of type pg_node_tree(which
seems to be already suggested by Robert). So may be we can proceed
On 12/5/14, 2:02 PM, Robert Haas wrote:
On Fri, Dec 5, 2014 at 2:52 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The other option would be to use some custom rowtype to store boundary
values and have a method that can form a boundary tuple from a real one.
Either way, I suspect this is better
that's huge because of shared buffers, but perhaps there's some way to
avoid writing those? (That means the core won't help if the bug is due to
something in a buffer, but that seems unlikely enough that the tradeoff is
worth it...)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data
On 12/5/14, 5:49 PM, Josh Berkus wrote:
On 12/05/2014 02:41 PM, Jim Nasby wrote:
Perhaps we should also officially recommend production servers be setup
to create core files. AFAIK the only downside is the time it would take
to write a core that's huge because of shared buffers, but perhaps
interface yet.
I've made some minor edits, with an emphasis on not changing original intent.
Each section was saved as a separate edit, so if anyone objects to something
just revert the relevant change. Once the code is available more editing can be
done.
--
Jim Nasby, Data Architect, Blue
On 12/7/14, 6:16 PM, Simon Riggs wrote:
On 20 October 2014 at 10:57, Jim Nasby jim.na...@bluetreble.com wrote:
Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
lock on, with no retry. Presumably this should be a rare occurrence, but I
think it's bad that we just
without requiring C. C isn't an option on many (even most)
environments in today's cloud world, aside from the intimidation factor.
There are comments in the code that hypothesize about making cstring a full type; that
might be all that's needed.
--
Jim Nasby, Data Architect, Blue Treble Consulting
on the disk.
If you think about it, partitioning is really a hack anyway. It clutters up
your logical set implementation with a bunch of physical details. What most
people really want when they implement partitioning is simply data locality.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data
for a catchall partition and supported normal inheritance/triggers on
that partition then users could continue to do whatever they needed with data that didn't fit the
normal partitioning pattern.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 12/8/14, 5:19 PM, Josh Berkus wrote:
On 12/08/2014 02:12 PM, Jim Nasby wrote:
On 12/8/14, 12:26 PM, Josh Berkus wrote:
4. Creation Locking Problem
high probability of lock pile-ups whenever a new partition is created on
demand due to multiple backends trying to create the partition
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing operators on text and varchar arrays.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble
thinking that in DefineRelation we can randomize
stmt-tableElts before merging in inheritance attributes.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 12/9/14, 4:30 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing operators on text and varchar arrays
the
holidays, but not before then.
FWIW, I suspect a call for help on -general or IRC would find volunteers for
any necessary data entry work...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list
because I don't feel I have enough knowledge to fulfill that
role.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
that calls a function as opposed to glomming a text string together
and passing that to EXECUTE.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 12/9/14, 5:06 PM, Jim Nasby wrote:
On 12/9/14, 4:30 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
On 12/9/14, 4:19 PM, Jim Nasby wrote:
Is there any particular reason we don't allow comparing char and varchar
arrays? If not I'll submit a patch.
We're also missing
On 12/12/14, 3:48 PM, Robert Haas wrote:
On Fri, Dec 12, 2014 at 4:28 PM, Jim Nasby jim.na...@bluetreble.com wrote:
Sure. Mind you, I'm not proposing that the syntax I just mooted is
actually for the best. What I'm saying is that we need to talk about
it.
Frankly, if we're going to require
On 12/12/14, 7:16 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
I'd say that array_eq (and probably _cmp) just needs to be taught to fall back
to what oper() does, but this part of the commit message gives me pause:
Change the operator search algorithms to look
in the server logfile, I think checking for the table is the right
answer.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
something if it times
out; otherwise you'll have a test failure and won't have any indication why.
I've attached a patch that adds logging on timeout and contains a test case
that demonstrates the rollback to savepoint bug.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble
that for all GUCs that include units, so presumably there's no good way
around it.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
a comment about that.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From a681953a802230e73e5e4f91607eca9dd99c34f2 Mon Sep 17 00:00:00 2001
From: Jim Nasby jim.na...@bluetreble.com
Date: Mon, 15 Dec 2014 18:35:50 -0600
Subject: [PATCH] Ignore
it untranslatable? Doesn't
the translation happen down-stream, so that at most we'd just need two
translation messages? Or worst case we could have two separate elog calls, if
we wanted to go that route.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
of for the later is something like failed initial lock
attempt. That's the only thing that will be true in all cases.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
be corrected.
If copying data/palloc is the root of numeric's performance problems then we
need to address that, because it will provide benefit across the entire
database. The pattern of (palloc; copy) is repeated throughout a large part of
the codebase.
--
Jim Nasby, Data Architect, Blue
it myself. :)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to decide what we're doing
first. ;)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
information cache|4
2 db hash|4
52 json object hashtable|64
28958 smgr relation table|16
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
diff --git a/src/backend/utils/hash/dynahash.c
b/src/backend/utils/hash/dynahash.c
index 5f6d6cb
On 12/18/14, 5:00 PM, Jim Nasby wrote:
2201582 20 -- Mostly LOCALLOCK and Shared Buffer
Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
be worth looking at, though it requires uint64.
It also occurs to me that we're needlessly shoving a lot of 0's into the hash
On 12/19/14, 5:13 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
On 12/18/14, 5:00 PM, Jim Nasby wrote:
2201582 20 -- Mostly LOCALLOCK and Shared Buffer
Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
be worth looking at, though it requires
to revise a commit message; it just makes downstream pulls
uglier if the commit was already pushed (see
https://help.github.com/articles/changing-a-commit-message/). It might be
possible to minimize or even eliminate that pain via git hooks.
--
Jim Nasby, Data Architect, Blue Treble Consulting
On 12/20/14, 11:51 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
What I am thinking is not using all of those fields in their raw form to
calculate the hash value. IE: something analogous to:
hash_any(SharedBufHash, (rot
.
...
In the above tests, it seems to me that the maximum benefit due to
'a' is realized upto 4~8 workers
I'd think a good first estimate here would be to just use
effective_io_concurrency.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
a command that allows you to apply a second command to every object in a
schema. We would have to be careful about PreventTransactionChain commands.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list
accumArrayResult. Currently, the code isn't using the rcontext for anything
except for old API calls (in first call to accumArrayResult).
Until we eliminate the API though, we should leave something in place that
still uses the old one, to make certain we don't accidentally break it.
--
Jim Nasby
-transactional commands dynamically, because VACUUM isn't the only one that
suffers from this problem.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of solving this only for vacuum we create something
generic? :) Possibly using Robert's background worker work?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 12/23/14, 7:44 AM, Robert Haas wrote:
On Mon, Dec 22, 2014 at 5:00 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I would MUCH rather that we find a way to special-case executing
non-transactional commands dynamically, because VACUUM isn't the only one
that suffers from this problem
On 12/20/14, 2:13 PM, Jim Nasby wrote:
On 12/20/14, 11:51 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
What I am thinking is not using all of those fields in their raw form to
calculate the hash value. IE: something analogous
On 12/24/14, 12:27 AM, Jim Nasby wrote:
There were several select-only runs on both to warm shared_buffers (set to
512MB for this test, and fsync is off).
BTW, presumably this ~380M database isn't big enough to show any problems with
hash collisions, and I'm guessing you'd need way more
On 12/23/14, 8:49 PM, Fabrízio de Royes Mello wrote:
Em terça-feira, 23 de dezembro de 2014, Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com escreveu:
On 12/23/14, 8:54 AM, Fabrízio de Royes Mello wrote:
Right now a lot of people just work around
On 12/24/14, 10:58 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-12-24 00:27:39 -0600, Jim Nasby wrote:
pgbench -S -T10 -c 4 -j 4
master:
tps = 9556.356145 (excluding connections establishing)
tps = 9897.324917 (excluding connections establishing)
tps = 9287.286907
that tells you the encoding for that entry?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
of a tapesort being faster than an
internal sort.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
to enforce RI rather than defining FKs precisely so that
they can get a serialization failure return code and do automatic
retry if it is caused by a race condition. That's less practical
to compensate for when it comes to unique indexes or constraints.
Wow, that's horrible. :(
--
Jim Nasby, Data
of the database.
My how this has become a can of worms...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
SELECT 1, but it would prevent a bunch of
pointless work on the backend side, and should greatly simplify DBD's ping().
Only thing I'm not sure of is if this could be made to be safe within a COPY...
:(
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
this, my inclination is DUMP with appropriate hints for
pg_dumpall, and BINARY.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
at fcinfo-flinfo-fn_expr, and I have no idea how likely that is to get
broken. Since it's a parse node, my guess is likely, but I'm just guessing.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list
?), and changing docs as needed?
Presumably that would be best as a separate patch...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
simultaneously? That would allow
things like
GroupAggregate
-- Sort(a) \
+-- Sort(a,b) -\
-- Hash(b) +
\-- SeqScan
That would allow the planner to trade off things like total memory consumption
vs IO.
--
Jim Nasby, Data Architect, Blue Treble
; that would come
later.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
things itself? Or
perhaps some custom command file that could then be replayed by pg_upgrade on
another server? Of course, that's assuming that replicas are compatible enough with
masters for that to work...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
SUPERUSER NOINHERIT NOLOGIN;
CREATE ROLE su_role IN ROLE su NOLOGIN;
GRANT su_role TO bob;
and have
su_role:*:*
Does bob get audited all the time then? Only when he does SET ROLE su? For that
matter, how does SET ROLE affect auditing?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble
there isn't really an issue here; I suspect ADAT is very rarely used.
What I'm worried about though is that someone is using it regularly for some
reason, with non-trivial databases, and this is going to completely hose them.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
to get the design pulled
together.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
and 8 workers make no
difference, then suddenly 16 cuts times by 1/2 to 1/3? Then 32 cuts time by
another 1/2 to 1/3?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
, but allow the user to over-ride
that.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
, what about:
foreach a,b in '{{{1,2},{3,4}},{{5,6},{7,8}}}'::int[] ?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
, it should be more (or differently) restrictive than SU, so
that you can effectively audit your superusers with minimal worries about
superusers tampering with auditing.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql
worker reading the
index and another worker taking index tuples and reading heap tuples...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
the operator caching code?
You should remove the array_length() from the last array_offsets test; I don't
see that it buys anything.
I think there should be tests for what happens when you feed these functions a
multi-dimensional array.
Other than that, looks good.
--
Jim Nasby, Data Architect
that
would be any different from an rsync --size-only in the end, presuming
everything went according to plan.
Yeah, if everything is shut down maybe we're OK.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers
).
Or maybe I'm missing something...
Wasn't the idea that the parent table in a partitioned table wouldn't actually
have a heap of it's own? If there's no heap there can't be an index.
That said, I think this is premature optimization that could be done later.
--
Jim Nasby, Data Architect, Blue
be better to just do this per-subtransaction.
I do agree that this needs to work across the board, not just for plpgsql.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
801 - 900 of 2196 matches
Mail list logo
