On 1/29/15 4:02 PM, Robert Haas wrote:
On Thu, Jan 29, 2015 at 4:09 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The difference between the autovacuum-run vacuum and the cron-run vacuum
is that the one running out of cron will just keep holding the lock
until it's actually able to truncate
not sure of is this:
+ /* Get the timestamp of the current statistics snapshot */
+ Datum
+ pg_stat_snapshot_timestamp(PG_FUNCTION_ARGS)
+ {
+ PG_RETURN_TIMESTAMPTZ(pgstat_fetch_global()-stats_timestamp);
+ }
Is the community OK with referencing stats_timestamp that way?
--
Jim Nasby, Data
On 1/28/15 7:27 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 1/28/15 9:56 AM, Stephen Frost wrote:
Such i/o systems do exist, but a single RAID5 group over spinning rust
with a simple filter isn't going to cut it with a modern CPU- we're just
too darn efficient
also be the tshirt for the next pgCon. ;)
--
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
others have made in this thread, for starters.
Your proposal seems intent on completely flattening all JSON documents,
or treating them as if they were flat. I see zero chance of that being
accepted.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
up
meaning), but I don't really care either way.
--
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
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Note that pgcrypto is failing 3 tests, same as in master.
The new
SeqScan performance
of tables that were relatively large. So bad that I had to SeqScan 8-16
tables in parallel to max out the IO system the same way I could with a
single dd bs=8k of a large file (in this case, something like 480MB/s).
A single SeqScan would only do something like 30MB/s.
--
Jim
On 4/20/15 4:13 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 03:58:19PM -0500, Jim Nasby wrote:
I also think there's better ways we could handle *all* our cleanup
work. Tuples have a definite lifespan, and there's potentially a lot
of efficiency to be gained if we could track tuples through
. At the minimum
it needs to be an assert().
Note that I haven't reviewed all the logic in detail at this point. If
this ends up being refactored it'll be a lot easier to spot logic
problems, so I'll hold off on that for now.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble
On 4/20/15 2:09 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 01:59:17PM -0500, Jim Nasby wrote:
On 4/20/15 1:48 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 04:45:34PM +0900, Sawada Masahiko wrote:
Attached WIP patch adds Frozen Map which enables us to avoid whole
table vacuuming even
, I suspect that won't happen during a single query.
I'll take a look at at least allowing passing a record in so you can
hand it to some other function. Any pointers on how to do that would be
welcome; I've never hacked on plpgsql or SQL function code before.
--
Jim Nasby, Data Architect, Blue
32k pages, which means
it'd be 128,000 times smaller than the heap. I have a hard time
believing that's going to be even a faint blip on the performance radar.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers
On 4/22/15 9:41 PM, Bruce Momjian wrote:
The case this doesn't catch is referencing a
symbolic link that points to the same directory. We can't make it an
error so people can use pg_upgrade these setups.
Couldn't we make it an ERROR unless IsBinaryUpgrade?
--
Jim Nasby, Data Architect, Blue
workloads you could have 80%+ of the tuples in a table
having a single inserting XID.
Dunno how much it would help for OLTP though... :/
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql
topic...
--
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
they need more than
one pass through the indexes due to exhausting maintenance_work_mem?
There's probably some fairly low-hanging fruit for parallelizing vacuum,
but it really depends on what problems people are running into.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
.
--
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 4/23/15 11:01 AM, Andres Freund wrote:
On April 23, 2015 6:12:05 PM GMT+03:00, Jim Nasby jim.na...@bluetreble.com
wrote:
On 4/22/15 9:41 PM, Bruce Momjian wrote:
The case this doesn't catch is referencing a
symbolic link that points to the same directory. We can't make it an
error so
.
3a: Other
Either we couldn't mark the page all-visible after hinting everything
from step 0, or there's newly deleted 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
can debate what we can do about it.
Also, what Robert posted was that while we started at something like
15%-30% larger, we ended the test at 80% larger. That makes me think
that the bigger win is not in reducing tuple size but tackling bloat.
--
Jim Nasby, Data Architect, Blue Treble Consulting
to 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 subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, presumably
it's a lot cheaper...
--
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
would be welcome. I think that in particular any
test data would be very useful to post there.
https://wiki.postgresql.org/wiki/Shared_Buffer_Improvements
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers
think people on -general might be very
interested. Now whether it's a good idea to hand them such a tool... ;)
--
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
this to the VM may work well to handle that. It
would double the size of the VM, but it would still be a ratio of
32,000-1 compared to heap size, or 2MB for a 64GB table.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql
On 4/21/15 4:07 PM, Peter Eisentraut wrote:
On 4/21/15 4:45 PM, Jim Nasby wrote:
In order for a background worker to keep up with some of the workloads
that have been presented as counterexamples, you'd need multiple
background workers operating in parallel and preferring to work on
certain
On 4/24/15 5:30 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
It looks like the biggest complaint (aside from allowing a limited number of
tuples to be moved) is in [1] and [2], where Tom is saying that you can't
simply call heap_update() like this without holding an exclusive lock on the
table
, but I think it's definitely worth
documenting.
--
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
.
--
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
. It might be fine --- I don't
know. People seem to focus on the big activities, while many small
activities can lead to larger slowdowns.
Ahh. This wouldn't be for the life of 200M transactions; it would be a
permanent fork, just like the VM is.
--
Jim Nasby, Data Architect, Blue Treble
(newly deleted). Unfortunately we still
wouldn't know whether we could do real work without visiting the page
itself, but I suspect that for many workloads just having newly
inserted/deleted would be a serious win.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
of that down.
--
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
event nonempty_pages could be used to set the guess as to how
many pages (if any) might be worth prefetching, as that is not needed
for correctness.
Yeah, but I think we'd do a LOT better with the VM idea, because we
could immediately truncate without scanning anything.
--
Jim Nasby, Data
tested around buffer management...
--
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
cleanup work.
Tuples have a definite lifespan, and there's potentially a lot of
efficiency to be gained if we could track tuples through their stages of
life... but I don't see any easy ways to do that.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
? The comments don't
explain it, and we have nonempty_pages as a starting point, so why don't
we just scan forward? I suspect that eons ago we didn't have that and
just blindly reverse-scanned until we finally hit a non-empty buffer...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data
to see what happened when it finished would definitely be
better than what's available now.
--
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
On 4/24/15 6:50 AM, Robert Haas wrote:
Thanks for looking at this.
On Thu, Apr 23, 2015 at 3:09 PM, Jim Nasby jim.na...@bluetreble.com wrote:
Unfortunately, the states I came up with using existing semantics don't look
hugely useful[4], but if we take Robert's idea and make all-visible mean
what Heikki did into contrib, and add the
necessary mode to heap_update?
--
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
outweigh making this a reloption anyway.
--
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
if
it's indexes or what.
--
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 4/24/15 3:34 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
Honestly, I'd prefer we exposed some way to influence where a new tuple gets
put, and perhaps better ways of accessing tuples on a specific page. That
would make it a lot easier to handle this in userspace, but it would also
make
On 4/28/15 1:31 PM, Andrew Dunstan wrote:
On 04/28/2015 01:44 PM, Jim Nasby wrote:
On 4/27/15 10:06 PM, Andrew Dunstan wrote:
My point remains that we really need methods of a) getting the field
names from generic records and b) using text values to access fields of
generic records, both
this could be user-visible (which as long as it's a manual
process I think is OK)?
--
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
way?
--
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
tried to search in archive, but not getting what is the exact
problem.
Unfortunately I can't find prior discussion now either... :/
--
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
no reason for these to be tied to
specific versions of Postgres. Adding to PGXN would make sense though.
(Though, I dislike using timestamps to do change/history tracking, but
that's just me...)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
On 4/25/15 6:30 AM, Simon Riggs wrote:
On 24 April 2015 at 22:36, Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com wrote:
Instead of adding forcefsm, I think it would be more useful to
accept a target block number. That way we can actually control where
the new
to far less than 4B
rows. If each row has 10 fields that toast, you'd be limited to just
400M rows.
--
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
time then you can handle it differently.
--
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
bigint language sql as $$
SELECT count(*)
FROM json_each_text( row_to_json($1) ) a
WHERE value IS NULL $$;
Attached patches both pass make check. The plpgsql is WIP, but I think
the SQL one is OK.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
)
+ TerminateBufferIO(bufHdr, false, 0);
+ else
+ TerminateBufferIO(bufHdr, false, BM_VALID);
Simply passing in a 0 seems a bit odd to me; is there anywhere else we
do that?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
on one point: the solution to
index bloat (and probably heap bloat, too) is not to clean it up
faster but to create less of it in the first place. Making more
updates HOT is one way to do that.
+1.
1:
http://stackoverflow.com/questions/16401294/how-to-know-linux-scheduler-time-slice
--
Jim
?
--
-1.00
(1 row)
The problem is that :: binds more tightly than -:
select (-1)::loan.loan_amount;
ERROR: value for domain loan.loan_amount violates check constraint
loan_amount__greater_equal_0
Is this by design? If not, any ideas how bad it'd be to fix?
--
Jim Nasby, Data Architect
.
To put this in perspective... I've seen things like this take query
runtime from minutes to multiple hours or worse; bad enough that
behavior break becomes a valid description.
We definitely need to highlight this in the release notes, and I think
the GUC would be mandatory.
--
Jim Nasby, Data
( random()*45000) ;
You could create a temp table with the random value and JOIN to it:
CREATE TEMP TABLE rnd AS SELECT random()*45000;
Another option might be to use a prepared statement:
PREPARE test AS SELECT ... WHERE customer_id = $1;
EXECUTE test( random()*45000 );
--
Jim Nasby, Data
@decina.local=# drop trigger t on t;
DROP TRIGGER
decibel@decina.local=# create trigger t before insert on t for each row
execute procedure tg('null');
CREATE TRIGGER
decibel@decina.local=# insert into t values('a');
ERROR: null is null? f
decibel@decina.local=#
--
Jim Nasby, Data Architect, Blue
in your VCS and the
database itself, but ISTM that's a much bigger problem than the small
amount of info we lose from stored functions...
--
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 backwards-compatibility
reasons. It also seems like rather a lot of new mechanism to add for
something with (evidently) near-zero user demand.
Ahh, I thought the array started life as an actual array, not char **.
So yeah, not nearly as easy to fix. :(
--
Jim Nasby, Data Architect, Blue
subselects...
--
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 4/29/15 12:18 PM, Robert Haas wrote:
On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem with just having the value is that if *anything* changes between
how you evaluated the value when you created the index tuple and when you
evaluate it a second time
ran about where
our 80% overhead was ending up? That would remove a lot of speculation
here...
--
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
and log the same way?
it affect client and log together
maybe min_context
+1
--
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
(such as
json_from_record()). Since that's my original motivation for looking at
this, I'd like that patch to be considered unless there's a big drawback
to it that I'm missing. (For 9.6, of course.)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
On 4/28/15 5:41 AM, José Luis Tallón wrote:
On 04/27/2015 08:49 AM, Jim Nasby wrote:
On 4/25/15 1:19 PM, Bruce Momjian wrote:
Note if you are storing a table with rows that exceed 2KB in size
(aggregate size of each row) then the Maximum number of rows in a
table may be limited
$$;
select t(); -- Expected error
alter table moo add t text;
select t(); -- Unexpected error
So it seems the correct fix would be to remember the list of every xmin
for every type we saw... unless there's some way to tie the proc into
type sinval messages?
--
Jim Nasby, Data Architect, Blue
one. We need a more general
approach.
Yeah. I think one of the big use cases here is that many environments
are OK with at least ident (if not trust) but only from the local
machine. So you'd probably want to handle that somehow.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data
cause big problems for.
--
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
for everytime the bottom-end
scheduler tries to start a job. Otherwise, the top has no clue what the
bottom has actually attempted.
To be clear, I don't think these need to be done in a first pass. I am
concerned about not painting ourselves into a corner though.
--
Jim Nasby, Data Architect, Blue Treble
something like that, but with no payload).
FWIW, numerous people made similar comments about Postgres at this
month's AustinPUG meeting when someone mentioned they haven't used it
yet. Basically, they said he'd love using it. :)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble
to fix, there's a typo in the comment for
IndexNextWithReorder (s/his/this/):
+ * Like IndexNext, but his version can also re-check any
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list
.
FWIW, having TIDGreaterOperator would be very useful for anyone trying
to un-bloat a table, so it'd be nice if this was at least available as a
PGXN extension.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql
don't think it's
fair to hold you accountable for people not stepping back up.
--
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
to accomplish 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-hackers
embed the magic
comment in your test statement instead of needing a separate call to
pg_backend_pid().
--
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
, but
everything else I do will be for 9.6.
Did it ever occur to you, Bruce, that you've turned into the GC daemon
for the project?
You mean... autovacuum? ;P
Hey, these reminder emails are kinda like hint bits afterall...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
it succeeded or not. (log in a table, not
just a logfile).
This isn't something that can be done at higher layers either; only the
scheduler will know if the job failed to even start, or whether it tried
to run the job.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
in the past...)
--
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
that sets us up for synchronization problems.
--
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
, not the FDW.
Of course, if you try to do a locking operation on an FDW that doesn't
support it, the FDW should throw an error... but that's different.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing
contain such functions in the patch, though.
I added that function and modified docs a bit. Please find attached an
updated version of the patch.
Why aren't we allowing SELECT FOR KEY SHARE?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
of greatly reducing the max for usage_count (maybe to 2
instead of 1 to simulate 2 pools), and running the clock sweep a lot
more aggressively in a background process.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql
stuff I get. If I had some way to
just over-ride the notion of diff the output I'd do that.
If I wasn't using pgTap I'm pretty sure I'd be having fun and games with
cross-version output tweaking.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http
with something too large to fit back into
storage. They might need to consider using something like bytea(990MB).
In any case, I don't think it would be terribly difficult to allow a bit
more than 1GB in a StringInfo. Might need to tweak palloc too; ISTR
there's some 1GB limits there too.
--
Jim Nasby
On 4/6/15 12:29 PM, k...@rice.edu wrote:
On Mon, Apr 06, 2015 at 12:07:47PM -0500, Jim Nasby wrote:
...
As I understand it, the goal here is to prevent huge amounts of
periodic freeze work due to XID wraparound. I don't think we need
the Freeze state to accomplish that.
With a single bit per
On 4/6/15 1:28 PM, Josh Berkus wrote:
On 04/06/2015 10:07 AM, Jim Nasby wrote:
Actually, I would start simply with ReadOnly and ReadWrite.
As I understand it, the goal here is to prevent huge amounts of periodic
freeze work due to XID wraparound. I don't think we need the Freeze
state
you actually freeze (which maybe
isn't worth it), but freezing isn't absolutely required. #2 would only
require that everything in the relation is visible; not frozen.
I think there's value here to having an ALLVISIBLE state as well as
ALLFROZEN.
--
Jim Nasby, Data Architect, Blue Treble
On 4/6/15 1:46 AM, Sawada Masahiko wrote:
On Sun, Apr 5, 2015 at 8:21 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sat, Apr 4, 2015 at 3:10 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 4/3/15 12:59 AM, Sawada Masahiko wrote:
+ case HEAPTUPLE_LIVE
On 4/6/15 11:12 AM, Sawada Masahiko wrote:
On Mon, Apr 6, 2015 at 10:17 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 4/6/15 1:46 AM, Sawada Masahiko wrote:
On Sun, Apr 5, 2015 at 8:21 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sat, Apr 4, 2015 at 3:10 PM, Jim Nasby jim.na
the problem
during development.
Why not just create a sequence? I suspect it may not be as fast to
assign as an OID, but it's not like you'd be doing this all the time.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql
with this? (FWIW, I'm in favor of it. Reporting the
feature isn't supported is confusing...)
--
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
the reason for using OIDs so that we're not doing the equivalent
of max(identifier) + 1?
Perhaps I'm just confused...
--
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 rename some field to something else.
Basically, another way to do what Alvaro is suggesting (though, the
ability to rename something is new...)
If we had that ability I think UPDATE * would become a lot more useful.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get
that TransactionIdIsCurrentTransactionId() does) and CommandId
CurrentCommandId?
I thought of this because of a post to -general. It's certainly not a
common case, but it seems like there's not much downside...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble
didn't even bother with a patch before
asking.
Thanks for setting me straight. :)
--
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
the hash code.
Anything happen with this, or the patch Andrew posted?
--
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 into a CommitFest
on this?
--
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 4/8/15 7:04 AM, Fujii Masao wrote:
I'm thinking to apply the attached patch.
But does anyone want to keep supporting the option? Why?
Nuke it.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing
.
BTW, you also need to put things in place to ensure it's impossible to
unfreeze a tuple in a relation that's marked ReadOnly or Frozen. I'm not
sure what the right way to do that would be.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
1101 - 1200 of 2196 matches
Mail list logo
