On 6/19/13 11:02 AM, Claudio Freire wrote:
On Wed, Jun 19, 2013 at 7:13 AM, Tatsuo Ishii wrote:
For now, my idea is pretty vague.
- Record info about modified blocks. We don't need to remember the
whole history of a block if the block was modified multiple times.
We just remember that t
ready have access to machines with a lot of cores, but I
haven't seen reports of large memory machines.
CPU details vary but we're only looking at 20ish cores (though AFAIK they're
all 4 socket servers if that matters).
Local drives are nothing fancy (though some might possibly be SSD)
I stand corrected... we don't have a 512G server available. We do have plenty
of 192G and 96G servers though if 2 of those would be of use.
Sorry for the noise.
On 6/21/13 11:48 AM, Jim Nasby wrote:
We've got some recently decommissioned servers and Enova is willing to donate 2
On 6/21/13 1:45 PM, Josh Berkus wrote:
On 06/21/2013 09:48 AM, Jim Nasby wrote:
We've got some recently decommissioned servers and Enova is willing to
donate 2 of them to the community.
There's nothing terribly spectacular about the servers except for
memory. We have one 512G server
On 6/17/13 3:38 PM, Josh Berkus wrote:
Why? Why can't we just update the affected pages in the index?
>
>The page range has to be scanned in order to find out the min/max values
>for the indexed columns on the range; and then, with these data, update
>the index.
Seems like you could incrementa
On 6/28/13 12:26 PM, Claudio Freire wrote:
On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby wrote:
On 6/17/13 3:38 PM, Josh Berkus wrote:
Why? Why can't we just update the affected pages in the index?
The page range has to be scanned in order to find out the min/max values
for the in
On 3/10/15 5:25 PM, Tom Lane wrote:
Jim Nasby writes:
That said, this pattern with fn_extra is repeated a lot, even just in
the backend (not counting contrib or extensions). It would be nice if
there was generic support for this.
What do you mean by "generic support"? Mos
ecognize this?
http://lnk.nu/github.com/1dvrr.c
--
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
longer build a fake VacuumStmt.
--
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
than above style.
The thing is, ()s are actually an odd-duck. Very little supports it, and
while COPY allows it they're not required. EXPLAIN is a different story,
because that's not WITH; we're actually using () *instead of* WITH.
So because almost all commands that use WITH
NULL when value is not found. It uses a "NOT DISTINCT FROM"
operator
+ * for comparation to be safe against NULL.
+ */
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
this
patch's job to solve that problem, but it would be nice.
Since this patch is here and ready to go I would prefer that we commit
it and refactor later. I can tackle that unless Pavel specifically wants to.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Troubl
On 3/11/15 1:19 AM, Pavel Stehule wrote:
2015-03-11 2:57 GMT+01:00 Robert Haas mailto:robertmh...@gmail.com>>:
On Tue, Mar 10, 2015 at 5:53 PM, Jim Nasby mailto:jim.na...@bluetreble.com>> wrote:
> I don't think we need both array_offset and array_offset_start;
On 3/13/15 6:48 AM, Robert Haas wrote:
On Wed, Mar 11, 2015 at 5:36 PM, Jim Nasby wrote:
The thing is, ()s are actually an odd-duck. Very little supports it, and
while COPY allows it they're not required. EXPLAIN is a different story,
because that's not WITH; we're actually us
overy target. Promotion should be
done via the normal promotion methods.
+1. "replay resume" certainly doesn't make me think "promote".
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hacke
hat I remember. There was discussion about how this should properly
support MD arrays.
--
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 t
ething close to it) on my whiteboard...
I think it's appropriate here ;)
"The perfect is the enemy of the good. -Simon Riggs"
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pg
them to munch their
data on accident doesn't help anyone.
--
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
that initdb sets and
nothing else. I'd be OK a coherent policy change in this area, but
just removing one or two setting seems like it will be confusing
rather than helpful.
I agree with not being ad-hoc (and I think a documented postgresql.conf
is much better than the other options
cause problems though. (In any case, I think
postgres is better than pgsql.)
StandardOutPath
/usr/local/pgsql/data/launchd.log
StandardErrorPath
/usr/local/pgsql/data/launchd.log
Wouldn't /var/log be better?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Troub
ariation of
this function that returns an array of ndims-1 that is the slice where a
value was found?
--
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 cha
I think it's long overdue.
+1
+1, but I also like the idea of allowing SU to connect during a smart
shutdown. Even if you've intentionally chosen smart instead of fast it
still sucks that you can't find out what's actually holding things up
(and ps isn't that great a
rying to
just flatten everything out. If a user wanted things flat they would
have just started with that in the first place.
--
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@postgresq
, they use multiple levels
of caching to avoid both parse costs as well as plan costs. It's always
impressed me that we didn't have to resort to such shenanigans, but
perhaps there's only so long we can avoid them.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Troubl
nts 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! h
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 st
s if milliseconds is more normal for logging that's OK.
FWIW, I don't see a problem with both %T and %M (whatever M ends 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
that they could always coalesce(...,
true).
--
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
nslations, and it's only ~15 lines. That doesn't seem very
unreasonable to me...
--
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
full_page_writes.
How about just grouping those 3 together with a bulk disclaimer along
the lines of "The following 3 settings are dangerous. Use at your own
risk, and read the docs first."? That would also allow us to just remove
the comments about what the settings do; if you do
stuff that initdb has
tweaked in 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
On 3/25/15 8:35 PM, Jeff Janes wrote:
On Wed, Mar 25, 2015 at 12:45 PM, Jim Nasby mailto:jim.na...@bluetreble.com>> wrote:
I see 3 settings that allow people to accidentally shoot themselves
in the foot; fsync, wal_sync_method and full_page_writes.
How about just grouping t
something
that's going to get handled entirely during query analysis, such as
casting a constant or utility commands. PortalRun is what you want when
there will be some kind of output, including DML.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http:
On 3/25/15 2:00 PM, Andres Freund wrote:
On 2015-03-25 14:50:44 -0400, Tom Lane wrote:
>Jim Nasby writes:
> >On 3/24/15 6:26 PM, Tom Lane wrote:
> >>Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
> >>to the makefiles, bu
blob;f=src/backend/access/nbtree/nbtree.c;hb=refs/heads/REL9_4_STABLE#l813
[2]
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/nbtree/nbtxlog.c;hb=refs/heads/REL9_4_STABLE#l482
--
May the force be with you…
https://simply.name
--
Jim Nasby, Data Architect, Blue
On 3/26/15 5:26 PM, David Fetter wrote:
+* Note: Non-positive years are take to be BCE.
s/take/taken/
--
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
for postgres. Can someone
tell me how to do that, where should I include this program so that I
can successfully implement that program in postgres.
Without seeing the program, no.
This also isn't the correct list; discussion like this should go on
pgsql-general@.
--
Jim Nasby, Data Arch
utovac settings. There may well be other settings in
there where it would not be safe.
--
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 sub
with ACLs. has_*_privilege does what it does well, but if you want to do
anything else (such as ensure permissions on an object are specified as
you expect) you're stuck resorting to things like
NOT EXISTS( SELECT has_*_privilege() FROM pg_roles WHERE rolname NOT IN() )
which is awkward
ue, this time related to bytea encoding.
There's probably several other places this type of thing could be a
problem. I'm thinking of conversions in particular.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via
ng like 480MB/s).
A single SeqScan would only do something like 30MB/s.
--
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
about race conditions with still running
transactions, etc.
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
On 4/4/15 5:10 PM, Jim Nasby wrote:
On 4/3/15 12:59 AM, Sawada Masahiko wrote:
+case HEAPTUPLE_LIVE:
+case HEAPTUPLE_RECENTLY_DEAD:
+case HEAPTUPLE_INSERT_IN_PROGRESS:
+case HEAPTUPLE_DELETE_IN_PROGRESS:
+if
On 4/6/15 1:46 AM, Sawada Masahiko wrote:
On Sun, Apr 5, 2015 at 8:21 AM, Jeff Janes wrote:
On Sat, Apr 4, 2015 at 3:10 PM, Jim Nasby wrote:
On 4/3/15 12:59 AM, Sawada Masahiko wrote:
+ case HEAPTUPLE_LIVE:
+ case
On 4/6/15 11:12 AM, Sawada Masahiko wrote:
On Mon, Apr 6, 2015 at 10:17 PM, Jim Nasby wrote:
On 4/6/15 1:46 AM, Sawada Masahiko wrote:
On Sun, Apr 5, 2015 at 8:21 AM, Jeff Janes wrote:
On Sat, Apr 4, 2015 at 3:10 PM, Jim Nasby
wrote:
On 4/3/15 12:59 AM, Sawada Masahiko wrote
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 bi
d 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, 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
t-in
framework, because of all the other 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 A
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
sta
need to
uncompact and re-compact for #1 when 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 we
that point. The only material
difference this makes is that it's much easier to notice 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 Archi
everything, 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 Tro
blems with
replication.
Maybe another reason to use standard Oids?
Wasn't 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 Trebl
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 yo
tra
stuff 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
deal with the missing sql directory
when someone sends in a patch.
What's happened on this?
Nothing has been committed, and as far as I understood this patch
could have been simply pushed...
Just so this doesn't get lost... did something make it into a CommitFest
on this?
--
at's why I 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
. So the next split would
actually help. But I think we can leave that up to probability, just
like all 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
--
Se
On 4/7/15 10:29 PM, Michael Paquier wrote:
On Wed, Apr 8, 2015 at 11:53 AM, Robert Haas wrote:
On Mon, Apr 6, 2015 at 1:51 PM, Jim Nasby wrote:
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 th
If you could provide some data that this was causing a real (not a
hypothetical) issue it'd be a lot easier to get the community excited
about it.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing
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 ma
ioned, it would be better to add helper functions to see
>> whether the foreign table is referenced by any ExecRowMarks. ISTM that
>> an easy way to do that is to modify ExecFindRowMark() so that it allows
>> for the missing case. I didn't contain such functions in the patch, thoug
error, 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 vi
e remote side (in this case, whether there's inheritance).
Anything like 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-hacke
I'd think the first thing we should try is a
combination 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
cal=#* DROP EXTENSION variant;
DROP EXTENSION
decibel@decina.attlocal=#* \dn
List of schemas
Name | Owner
-+-
public | decibel
variant | decibel
(2 rows)
decibel@decina.attlocal=#* DROP SCHEMA variant ;
DROP SCHEMA
decibel@decina.attlocal=#* \q
--
Jim Nasby, Data Archit
d are NULL. I can do it in pure SQL (below), but was
hoping to wrap the entire thing in a function. Right now, I have to add
a call to row_to_json() to the function call.
SELECT count(*)
FROM json_each_text( row_to_json($1) ) a
WHERE value IS NULL
--
Jim Nasby, Data Architect, Blue Treble Consu
On 4/19/15 5:08 PM, Tom Lane wrote:
Jim Nasby writes:
CREATE EXTENSION creates the variant schema for me, but it leaves it
behind when I drop the extension. I assume this is a bug and not by design?
No, it's intentional. If you want the schema to be considered part of the
extension,
nyway? 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
it
would stay cleared.
Right.
In any 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 w
h all the ideas that
have been 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-hackers
*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 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? Ge
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
tuples as visible/frozen that shouldn't be. We should probably throw an
error here, because it means the heap is now corrupted. 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
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 tupl
oing to be free, 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.postgresq
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
sted there, but help 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
--
Se
fork
for every table would exacerbate that problem considerably.
Andres idea of adding 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
e has gotten around 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
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
ce
ady dirtying, especially if we can keep the WAL cost 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
a
function argument.
--
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
uning (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?
REEZE. 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 Archite
ned, would 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
Dat
nt
base type. In reality, 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 bef
XIDs. In many 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 mail
enough where you'll care, you'll also be using 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
ly
around things like fcinfo, but that's another 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
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
this use.
Actually, there may be some bit manipulation functions we could reuse;
things like efficiently counting how many things in a byte are set.
Probably doesn't make sense to fully refactor it, but at least CLOG is a
good source for cut/paste/whack.
--
Jim Nasby, Data Architect, B
tation of types from what's
passed around internally. That might offer some gains here, even if it's
just in reducing the need for alignment.
I also wonder if a similar technique would be useful at the tuple level.
One possibility would be attempting to compress the tuple before pu
t has
no newly inserted nor newly deleted tuples.
2a: All-frozen
Not only is the page all-visible, it's also all-frozen.
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 Archit
nd
then we 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
is
intentional, but it'd be nice if we could consolidate it more.
--
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
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 people can use
ing able 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 t
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/pgsql-hackers
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 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
all-frozen,
601 - 700 of 2230 matches
Mail list logo
