On Mon, Jul 18, 2016 at 10:05 AM, Tom Lane wrote:
> Jan Wieck writes:
> > In the meantime, would it be appropriate to backpatch the double linking
> > of memory context children at this time? I believe it has had plenty of
> > testing in the 9.6 cycle to be sure it
ecuted.
But such a change definitely needs more testing and probably won't
qualify for backpatching.
In the meantime, would it be appropriate to backpatch the double linking
of memory context children at this time? I believe it has had plenty of
testing in the 9.6 cycle to be sure it didn't break anything.
Regards, Jan
--
Jan Wieck
Senior Postgres Architect
http://pgblog.wi3ck.info
multi-threaded process are
huge. Think of snapshot visibility together with catalog cache
invalidations.
I'd say no to that one as a first step.
But multi-threading the executor or even certain utility commands at first
should not be rejected purely on the notion that "we don't have
multithreadin
BTW, here is the email thread about double-linking MemoryContext children
patch, that Kevin at the end committed to master.
https://www.postgresql.org/message-id/55F2D834.8040106%40wi3ck.info
Regards, Jan
On Sat, Jul 16, 2016 at 3:47 PM, Jan Wieck wrote:
>
>
> On Tue, Jul 12, 201
a Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
> 855-TREBLE2 (855-873-2532) mobile: 512-569-9461
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Jan Wieck
Senior Postgres Architect
http://pgblog.wi3ck.info
in a trivial database implementation, where an ALTER TABLE is
just trampling over a running transaction.
Regards, Jan
--
Jan Wieck
Senior Postgres Architect
http://pgblog.wi3ck.info
statements and a impossible to utilize any cached
> plans.
>
> This is not an academic gripe -- I just exploded production :-D.
>
> merlin
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Jan Wieck
Senior Postgres Architect
ine to still find those blocks in memory. Basically we
are talking about the active portion of your database, shared buffers,
the sum of all process local memory and the complete pg_xlog directory
content fitting into RAM.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Se
On 09/18/2015 10:47 AM, Tom Lane wrote:
Jan Wieck writes:
Attached is a complete rework of the fix from scratch, based on Tom's
suggestion.
The code now maintains a double linked list as suggested, but only uses
it to mark all currently valid entries as invalid when hashvalue == 0.
On 09/15/2015 12:02 PM, Jan Wieck wrote:
On 09/15/2015 11:54 AM, Tom Lane wrote:
Jan Wieck writes:
Would it be appropriate to use (Un)RegisterXactCallback() in case of
detecting excessive sequential scanning of that cache and remove all
invalid entries from it at that time?
Another idea is
On 09/15/2015 11:54 AM, Tom Lane wrote:
Jan Wieck writes:
Would it be appropriate to use (Un)RegisterXactCallback() in case of
detecting excessive sequential scanning of that cache and remove all
invalid entries from it at that time?
Another idea is that it's not the size of the
On 09/15/2015 10:58 AM, Tom Lane wrote:
I wrote:
Jan Wieck writes:
I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it
definitely is caused by this commit. Do you want to back it out for the
time being? Kevin is on vacation right now.
I'll take a look today, and
On 09/15/2015 09:51 AM, Tom Lane wrote:
Jan Wieck writes:
On 09/14/2015 09:56 AM, Tom Lane wrote:
Kevin Grittner writes:
Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particul
gards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ed to change both places
that are affected, so ResourceOwnerCreate() in resowner.c would
need a line or two added.
ResourceOwnerCreate() sets ResourceOwnerData.nextchild, not
MemoryContextData.nextchild.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-ha
On 09/11/2015 09:58 AM, Tom Lane wrote:
Jan Wieck writes:
On 09/11/2015 09:38 AM, Tom Lane wrote:
Seems less invasive to fix SPI to delete in the opposite order?
That would assume that there are no other code paths that destroy memory
contexts out of LIFO order.
Given that we've not
On 09/11/2015 09:38 AM, Tom Lane wrote:
Jan Wieck writes:
The attached script demonstrates an O(N^2) problem we recently became
aware of. The script simply executes a large anonymous code block that
doesn't do anything useful. Usage is
./t1.py [NUM_STMTS] | psql [DBNAME]
NUM_
patch makes MemoryContext children a double linked list
that no longer needs any list traversal no find the position of the
child within the list.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.c
On 09/08/2015 08:49 AM, Kevin Grittner wrote:
Jan Wieck wrote:
The problem is a cache introduced in commit 45ba4247 that improves
That's a bit off; 45ba424f seems to be what you mean.
Copy paste over paper.
foreign key lookups during bulk updates when the FK value does not
c
supposed to improve.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
diff --git a/src/backend/utils/adt/ri_triggers.c b/src/backend/utils/adt/ri_triggers.c
index 61edde9..d7023ce 100644
--- a/src/backend/utils/adt/ri_triggers.c
+++ b/src/backend/utils/adt/ri_triggers.c
@@ -183,6
bottleneck has on 9.5.
Sorry for the noise, Jan
On 06/10/2015 09:18 AM, Jan Wieck wrote:
Hi,
I think I may have found one of the problems, PostgreSQL has on machines
with many NUMA nodes. I am not yet sure what exactly happens on the NUMA
bus, but there seems to be a tipping point at which the
physical-RAM / concurrent-connections depending on the
complexity of your queries. 48GB does not sound reasonable.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
ic fashion that does not
hurt other platforms will still give us something.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/10/2015 11:06 AM, Nils Goroll wrote:
On 10/06/15 16:18, Jan Wieck wrote:
I have played with test code that isolates a stripped down version of s_lock()
and uses it with multiple threads. I then implemented multiple different
versions of that s_lock(). The results with 200 concurrent
On 06/10/2015 10:59 AM, Robert Haas wrote:
On Wed, Jun 10, 2015 at 10:20 AM, Tom Lane wrote:
Jan Wieck writes:
The attached patch demonstrates that less aggressive spinning and (much)
more often delaying improves the performance "on this type of machine".
Hm. One thing worth ask
On 06/10/2015 10:20 AM, Tom Lane wrote:
Jan Wieck writes:
The attached patch demonstrates that less aggressive spinning and (much)
more often delaying improves the performance "on this type of machine".
Hm. One thing worth asking is why the code didn't converge to
h the assembler xchgb operation used by PostgreSQL
today on x84_64.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/10/2015 09:28 AM, Andres Freund wrote:
On 2015-06-10 09:18:56 -0400, Jan Wieck wrote:
On a machine with 8 sockets, 64 cores, Hyperthreaded 128 threads total, a
pgbench -S peaks with 50-60 clients around 85,000 TPS. The throughput then
takes a very sharp dive and reaches around 20,000 TPS
t; #cores, so
the real solution will probably look much different. But I thought it
would be good to share this and start the discussion about reevaluating
the spinlock code before PGCon.
Regards, Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
diff --git a/src/backend/storage/lm
On 02/05/2015 02:15 PM, Jan Wieck wrote:
On 02/05/2015 01:18 PM, Marko Tiikkaja wrote:
"pgcrypto bug"
That doesn't look too good, but I can't reproduce it against 9.3.6 either.
Attached is an improved script and the final output from it. I ran it
over night and
On 02/05/2015 01:18 PM, Marko Tiikkaja wrote:
On 2/5/15 4:48 PM, Jan Wieck wrote:
What the script does is to encode a small string with pgp_sym_encrypt()
and then repeatedly try to decrypt it with different "wrong" passwords.
The expected error message for that is of course
&qu
On 02/05/2015 10:58 AM, Tom Lane wrote:
Jan Wieck writes:
I have encountered a small instability in the behavior of pgcrypto's
pgp_sym_decrypt() function. Attached is a script that can reproduce the
problem. It may have to be run repeatedly because the symptom occurs
rather seldom.
Wha
o or if this is an
error inherent in the way, the encrypted data is encoded. I.e. that the
decryption algorithm cannot really figure out what is wrong and just
sometimes gets a little further in the attempt to decrypt.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
pgcrypto_test
those be moved back to
where they used to be?
Slony uses the definitions in external tools, like slon and slonik, to
format sequence numbers in log output.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers
information for those cases and I believe
that tackling them one at a time in depth will lead to more useful
results than trying to cover a lot but shallow.
My $.02
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 10/01/2014 01:32 PM, Andres Freund wrote:
On 2014-10-01 13:22:53 -0400, Jan Wieck wrote:
On 10/01/2014 01:19 PM, Andres Freund wrote:
>On 2014-10-01 13:17:17 -0400, Jan Wieck wrote:
>>>>-static void StreamLog();
>>>>+static void StreamLogicalLog();
>>>
On 10/01/2014 01:19 PM, Andres Freund wrote:
On 2014-10-01 13:17:17 -0400, Jan Wieck wrote:
>>-static void StreamLog();
>>+static void StreamLogicalLog();
>>Not related at all to those patches, but for correctness it is better to
>>add a declaration "(void)".
ch.
Greetings,
Andres Freund
You might want to do that function renaming in pg_receivexlog.c as well.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the discussion.
If there indeed has to be a catversion bump in the process of this, then
I agree with Craig.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
issed?
But it's another thing if we design specific syntax that encourages such
abuse, as proposed earlier.
The design should explicitly discourage that sort of nonsense.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
ually found inside of complex code
constructs to check values of local variables. I don't think it is even
a good idea to implement assertions that can query arbitrary data.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgs
bout 700 x the average, which is still reasonable if you
run a decent number of transactions. And of course, the probability of
hitting such an extreme value is miniscule, so if you're just doing a
few quick test runs with a small total number of transactions, you won't
hit that.
- Heik
check the list archives for it.
+1 on the OUT alias.
-1 on the ASSERT as proposed. It would be too easy for application
developers to abuse them to govern business logic and a DBA later
turning off assertions for performance reasons.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://
alone cannot be the default.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/06/2014 12:33 PM, Marko Tiikkaja wrote:
On 2014-09-06 6:31 PM, Jan Wieck wrote:
On 09/06/2014 12:17 PM, Marko Tiikkaja wrote:
OK, fine. But that's not what I suggested on the wiki page, and is also
not what I'm arguing for here right now. What the message you referred
to was
sets. No matter how hard you
try to make them special, in my mind they are not.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
abase
system, you try to make it foolproof.
Guess what, the second you made something foolproof, evolution will
create a dumber fool. This is a race you cannot win.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-ha
nsure that at maximum one row is affected, then qualify it by a unique
set of columns. Making PL/pgSQL behave different on UPDATE than SQL to
enforce that by default was simply a misguided design idea.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hacke
t. Since I am on vacation next
week, getting ready for my first day at EnterpriseDB, this may actually
happen.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
(default 2 seconds).
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
NOT NULL pk"? really?).
It is about semantic and conformity of proposed tools. Sure, all can
reduced to ASSERT(expr) .. but where is some benefit against function call
I am able to do without any change of language as plpgsql extension -
there is no necessary to do any change for too thin
nput data would make it fail again, even with lengths.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t array at the beginning.
Would changing 1024 to a fraction of the datum length for the time being
give us enough room to come up with a proper solution for 9.5?
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
he API, we
might as well do it right.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
arser,
not into the PL.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/04/2014 09:31 AM, Pavel Stehule wrote:
2014-09-04 15:24 GMT+02:00 Jan Wieck
Making the COMMAND CONSTRAINT part of the core SQL parser was how I
understood Hannu's idea. It would be horrible to tuck that feature away
inside of a PL, rather than making it available to all PLs as we
d and become
identified by the error message, is the actual SELECT (or other DML
statement).
I think I like the COMMAND CONSTRAINT the best so far.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
ts own language, based on all the possible permutations
of those PRAGMA/GUC settings.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e worth it after all. And I mean that. No sarcasm.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
oad kill on the side of the highway for a
decade already.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he way it's used
for INTO because it's referring to the INTO. And it's much more obvious
what it could mean there.
For once I completely agree with Andres.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
plpgsql or plpgsql2. If you
cannot get that same syntax to apply to default client queries, then the
whole idea is bogus because it will confuse developers more than it
helps you with your particular way of thinking.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent
ke that "pretty" and "performant"?
Because the moment, your "pretty" language is out there, be sure users
will kick your behind that whenever they use that "pretty" stuff on
anything but a toy setup, it spirals their servers into a DOS attack state.
ach
UPDATE command.
Your idea of what an OLTP application is seems flawed.
b) Data warehouseing applications where you process multiple rows in
each UPDATE command.
Ditto.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgs
st of all it is
[DECLARE
declarations]
BEGIN
statements
END;
Second "statements" includes the whole definition above as a "statement"
and controls identifier visibility and such compatible to PL/SQL.
You want to lose that? Not such a great idea, IMHO.
Jan
--
Jan Wieck
ore selective on that one.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
om throwing that sort of sh*t at Slony at full speed.
Not trying to discourage anyone from trying. Just saying that it doesn't
fit into our existing regression test framework.
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 04/13/14 14:22, Jan Wieck wrote:
On 04/13/14 08:27, Marko Kreen wrote:
I think you need to do SET_VARSIZE also here. Alternative is to
move SET_VARSIZE after sort_snapshot().
And it seems the drop-double-txid logic should be added also to
txid_snapshot_recv(). It seems weird to have it
On 04/13/14 08:27, Marko Kreen wrote:
On Sat, Apr 12, 2014 at 02:10:13PM -0400, Jan Wieck wrote:
Since it doesn't seem to produce any side effects, I'd think that
making the snapshot unique within txid_current_snapshot() and
filtering duplicates on input should be sufficient and el
On 04/12/14 10:03, Andres Freund wrote:
On 2014-04-12 09:47:24 -0400, Tom Lane wrote:
Heikki Linnakangas writes:
> On 04/12/2014 12:07 AM, Jan Wieck wrote:
>> the Slony team has been getting seldom reports of a problem with the
>> txid_snapshot data type.
>> The symptom is
On 04/12/14 11:18, Andres Freund wrote:
On 2014-04-12 11:15:09 -0400, Jan Wieck wrote:
On 04/12/14 10:09, Greg Stark wrote:
>A pg_restore would start a new xid space from FirstNormalXid which would
>obviously not work with any stored txids.
>
http://www.postgresql.org/docs/9.3/s
On 04/12/14 10:09, Greg Stark wrote:
A pg_restore would start a new xid space from FirstNormalXid which would
obviously not work with any stored txids.
http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
that when glancing over the code earlier.
Right, that is easy enough and looks like an acceptable fix for back
branches too.
Thanks,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 04/12/14 03:27, Heikki Linnakangas wrote:
On 04/12/2014 12:07 AM, Jan Wieck wrote:
Hackers,
the Slony team has been getting seldom reports of a problem with the
txid_snapshot data type.
The symptom is that a txid_snapshot on output lists the same txid
multiple times in the xip list part of
functional change for a back release, but considering
that the _out() generated external representation of an existing binary
datum won't pass the type's _in() function, I argue that such change is
warranted. Especially since this problem could possibly corrupt a dump.
Comments?
Jan
On 06/19/13 14:34, Fabien COELHO wrote:
>
>>> The use case of the option is to be able to generate a continuous gentle
>>> load for functional tests, eg in a practice session with students or for
>>> testing features on a laptop.
>>
>> Why does this need two option formats (-H and --throttle)?
>
On 05/01/13 04:57, Fabien COELHO wrote:
>
> Add --throttle to pgbench
>
> Each client is throttled to the specified rate, which can be expressed in
> tps or in time (s, ms, us). Throttling is achieved by scheduling
> transactions along a Poisson-distribution.
>
> This is an update of the previ
On 4/18/2013 11:44 AM, Jan Wieck wrote:
Yes, that was the rationale behind it combined with "don't change
function call sequences and more" all over the place.
function call signatures
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Be
On 4/12/2013 2:08 PM, Alvaro Herrera wrote:
Tom Lane escribió:
Are you saying you intend to revert that whole concept? That'd be
okay with me, I think. Otherwise we need some thought about how to
inform the stats collector what's really happening.
Maybe what we need is to consider table tru
On 4/12/2013 1:57 PM, Tom Lane wrote:
Kevin Grittner writes:
Tom Lane wrote:
I think that the minimum appropriate fix here is to revert the hunk
I quoted, ie take out the suppression of stats reporting and analysis.
I'm not sure I understand -- are you proposing that is all we do
for both
On 12/20/2012 4:47 PM, Dimitri Fontaine wrote:
Tom Lane writes:
The reason this fails is that you've got a half-megabyte source string,
and each of the 11000 plans that are due to be created from it saves
its own copy of the source string. Hence, 5500 megabytes needed just
for source strings.
On 12/14/2012 3:20 PM, Robert Haas wrote:
On Fri, Dec 14, 2012 at 2:11 PM, Tom Lane wrote:
Robert Haas writes:
... In more
than ten years of working with PostgreSQL, I've never encountered
where the restriction at issue here prevented a bug. It's only
annoyed me and broken my application co
On 12/12/2012 3:12 PM, Simon Riggs wrote:
On 12 December 2012 19:13, Jan Wieck wrote:
On 12/12/2012 1:12 PM, Simon Riggs wrote:
Currently, ANALYZE collects data on all columns and stores these
samples in pg_statistic where they can be seen via the view pg_stats.
In some cases we have data
On 12/12/2012 1:12 PM, Simon Riggs wrote:
Currently, ANALYZE collects data on all columns and stores these
samples in pg_statistic where they can be seen via the view pg_stats.
In some cases we have data that is private and we do not wish others
to see it, such as patient names. This becomes mor
On 12/9/2012 2:37 PM, Kevin Grittner wrote:
Jan Wieck wrote:
Based on the discussion and what I feel is a consensus I have
created an updated patch that has no GUC at all. The hard coded
parameters in include/postmaster/autovacuum.h are
AUTOVACUUM_TRUNCATE_LOCK_CHECK_INTERVAL 20 /* ms
I am aware that in the case at hand, the call to make_fn_arguments() is
with the only possible candidate function, so changing COERCE_IMPLICIT
to COERCE_ASSIGNMENT inside of make_fn_arguments() is correct. But I
wonder if this may have any unwanted side effects for other code paths
to make_fn_a
On 12/6/2012 12:45 PM, Robert Haas wrote:
On Wed, Dec 5, 2012 at 10:16 PM, Jan Wieck wrote:
That sort of "dynamic" approach would indeed be interesting. But I fear that
it is going to be complex at best. The amount of time spent in scanning
heavily depends on the visibility map. T
Kevin and Robert are well aware of most of the below. I just want to put
this out here so other people, who haven't followed the discussion too
closely, may chime in.
Some details on the problem:
First of all, there is a minimum number of 1000 pages that the vacuum
scan must detect as possibl
On 12/5/2012 2:00 PM, Robert Haas wrote:
Many it'd be sensible to relate the retry time to the time spend
vacuuming the table. Say, if the amount of time spent retrying
exceeds 10% of the time spend vacuuming the table, with a minimum of
1s and a maximum of 1min, give up. That way, big tables w
On 12/4/2012 1:51 PM, Kevin Grittner wrote:
Jan Wieck wrote:
[arguments for GUCs]
This is getting confusing. I thought I had already conceded the
case for autovacuum_truncate_lock_try, and you appeared to spend
most of your post arguing for it anyway. I think. It's a little
hard to
On 12/4/2012 8:06 AM, Kevin Grittner wrote:
Jan Wieck wrote:
I believe the check interval needs to be decoupled from the
deadlock_timeout again.
OK
This will leave us with 2 GUCs at least.
Hmm. What problems do you see with hard-coding reasonable values?
The question is what is
On 12/3/2012 5:42 PM, Kevin Grittner wrote:
Jan Wieck wrote:
Attached is a new patch that addresses most of the points raised
in discussion before.
1) Most of the configuration variables are derived from
deadlock_timeout now. The "check for conflicting lock request"
i
Attached is a new patch that addresses most of the points raised in
discussion before.
1) Most of the configuration variables are derived from deadlock_timeout
now. The "check for conflicting lock request" interval is
deadlock_timeout/10, clamped to 10ms. The "try to acquire exclusive
lock" i
On 11/29/2012 9:46 AM, Tom Lane wrote:
Jan Wieck writes:
On 11/28/2012 3:33 PM, Kevin Grittner wrote:
Resetting starttime this way seems especially odd.
instr_time is LARGE_INTEGER on Win32 but struct timeval on Unix. Is
starttime = currenttime;
portable if those are structs?
Sure
On 11/28/2012 3:33 PM, Kevin Grittner wrote:
Kevin Grittner wrote:
I still need to review the timing calls, since I'm not familiar
with them so it wasn't immediately obvious to me whether they
were being used correctly. I have no reason to believe that they
aren't, but feel I should check.
It
On 10/28/2012 10:50 PM, Peter Geoghegan wrote:
On 28 October 2012 22:35, Jan Wieck wrote:
The amount of WAL generated with full_page_writes=on is quite substantial.
For pgbench for example the ratio 20:1. Meaning with full_page_writes you
write 20x the amount you do without.
Sure, but as
On 10/27/2012 2:41 PM, Heikki Linnakangas wrote:
And it's not at all
clear to me that it would perform better than full_page_writes. You're
writing and flushing out roughly the same amount of data AFAICS.
I think this assumption is wrong. full_page_writes=on means we write the
full page conten
I just had this thought a few minutes ago, discussed it briefly with
RhodiumToad on #postgresql and wanted to put it out here for discussion.
Feel free to rip it apart. It probably is a bit "al-dente" at this point
and needs more cooking.
The reason why we need full_page_writes is that we need
I just had this thought a few minutes ago, discussed it briefly with
RhodiumToad on #postgresql and wanted to put it out here for discussion.
Feel free to rip it apart. It probably is a bit "al-dente" at this point
and needs more cooking.
The reason why we need full_page_writes is that we need
On 10/26/2012 6:35 AM, Amit Kapila wrote:
On Friday, October 26, 2012 11:50 AM Jan Wieck wrote:
On 10/26/2012 1:29 AM, Amit Kapila wrote:
>One other way could be to check after every few pages for a
conflicting
> lock request.
How is this any different from what my patch does?
1 - 100 of 970 matches
Mail list logo
