On 11 Dec. 2016 06:50, "Petr Jelinek" wrote:
On 10/12/16 23:10, Petr Jelinek wrote:
>
> The attached 0002-Skip-unnecessary-snapshot-builds.patch changes this
> behavior so that we don't make snapshots for transactions that we seen
> wholly and know that they didn't make catalog changes even if we
On 11 Dec. 2016 07:44, "Tom Lane" wrote:
I think we need to do at least this much for v10, because otherwise
we'll face ABI issues if an extension is compiled against code with
one semaphore API choice and used with code with a different one.
+1, this is a good idea. Your performance comments
On Thu, Dec 8, 2016 at 2:38 AM, Andreas Seltenreich wrote:
> Andreas Seltenreich writes:
>
>> Amit Kapila writes:
>>
>>> On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich
>>> wrote:
Amit Kapila writes:
> [2. text/x-diff; fix_hash_bucketsplit_sqlsmith_v1.patch]
Ok, I'll do te
On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes wrote:
> On Tue, Dec 6, 2016 at 4:00 AM, Amit Kapila wrote:
>>
>> On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes wrote:
>> >
>> >
>> > I just occasionally insert a bunch of equal tuples, which have to be in
>> > overflow pages no matter how much splitting h
2016-12-10 7:11 GMT+01:00 Pavel Stehule :
>
>
> 2016-12-10 2:27 GMT+01:00 Jim Nasby :
>
>> On 12/9/16 9:39 AM, Pavel Stehule wrote:
>>
>>>
>>> SELECT image FROM accounts WHERE id = xxx
>>> \gstore_binary ~/image.png
>>>
>>> What do you think about this proposal?
>>>
>>
>> Seems reasonable.
>>
>> I
On Sun, Dec 11, 2016 at 8:14 AM, Peter Geoghegan wrote:
> I noticed that the partially parallelized Merge Join EXPLAIN ANALYZE
> that you attach has a big misestimation:
>
> -> Merge Join (cost=3405052.45..3676948.66 rows=320 width=32)
> (actual time=21165.849..37814.551 rows=1357812 loops=4)
>
On Sat, 10 Dec 2016 19:41:21 -0600
"Karl O. Pinc" wrote:
> On Fri, 9 Dec 2016 23:36:12 -0600
> "Karl O. Pinc" wrote:
>
> > Instead I propose (code I have not actually executed):
> > ...
> > charlbuffer[MAXPGPATH];
> > char*log_format = lbuffer;
> > ...
> >
> > /* extract log format
On Sat, Dec 10, 2016 at 4:59 AM, Dilip Kumar wrote:
> 3. 20_patch.out : Explain analyze output with patch (median of 3 runs)
I noticed that the partially parallelized Merge Join EXPLAIN ANALYZE
that you attach has a big misestimation:
-> Merge Join (cost=3405052.45..3676948.66 rows=320 width=
On Fri, 9 Dec 2016 23:36:12 -0600
"Karl O. Pinc" wrote:
> Instead I propose (code I have not actually executed):
> ...
> charlbuffer[MAXPGPATH];
> char*log_format = lbuffer;
> ...
>
> /* extract log format and log file path from the line */
> log_filepath = strchr(lbuffer, ' ');
Regards,
Venkata B N
Database Consultant
On Fri, Dec 9, 2016 at 11:11 PM, Amit Langote
wrote:
> On Fri, Dec 9, 2016 at 3:16 PM, Venkata B Nagothi
> wrote:
> > Hi,
> >
> > I am testing the partitioning feature from the latest master and got the
> > following error while loading the data -
> >
Robert Haas writes:
> On Thu, Dec 8, 2016 at 3:53 AM, Srinivas Karthik V
> wrote:
>> 1) Can you please let me know if innerbucketsize*innerpathrows captures the
>> maximum bucket size?
>> 2) why is it not calculated afresh all the time?
> Well, #2 is answered there right in the comments:
>
On 11/26/16 12:30 AM, Jim Nasby wrote:
On 11/25/16 6:00 PM, Tom Lane wrote:
OIDs? Then use pg_describe_object() to turn that into text when dumping.
How would I get pg_dump to do that?
I could certainly make this work if there was some way to customize how
pg_dump dumps things, but AFAIK the
jascana (mingw, 64 bit compiler, no openssl) is currently hung on "make
check". After starting the autovacuum launcher there are 120 messages on
its log about "Could not acquire random number". Then nothing.
So I suspect the problem here is commit
fe0a0b5993dfe24e4b3bcf52fa64ff41a444b8f1, a
Robert Haas writes:
> On Wed, Dec 7, 2016 at 3:12 PM, Tom Lane wrote:
>> As things stand, it's only a configure-time choice, but I've been
>> thinking that we might be well advised to make it run-time configurable.
> Sure. A configure-time choice only benefits people who are compiling
> from so
On 12/10/16 1:02 PM, Christophe Pettus wrote:
On Dec 9, 2016, at 22:52, Keith Fiske wrote:
On Fri, Dec 9, 2016 at 10:01 PM, Robert Haas wrote:
One thing that's tricky/annoying about this is that if you have a
DEFAULT partition and then add a partition, you have to scan the
DEFAULT partition
On 10/12/16 23:10, Petr Jelinek wrote:
>
> The attached 0002-Skip-unnecessary-snapshot-builds.patch changes this
> behavior so that we don't make snapshots for transactions that we seen
> wholly and know that they didn't make catalog changes even if we didn't
> reach consistency yet.
>
Eh, attach
Hi,
I recently found couple of issues with the way initial logical decoding
snapshot is made.
First one is outright bug, which has to do with how we track running
transactions. What snapbuild basically does while doing initial snapshot
is read the xl_running_xacts record, store the list of runnin
Hi,
2016-12-07 9:06 GMT+03:00 Andreas Seltenreich :
> Hi,
>
> the following query crashes master as of 4212cb7.
>
> select ts_rewrite(
> tsquery_phrase(
> tsquery $$'sanct' & 'peter'$$,
> tsquery $$'5' <-> '6'$$,
> 42),
> tsquery $$'5' <->
> On Dec 9, 2016, at 22:52, Keith Fiske wrote:
> On Fri, Dec 9, 2016 at 10:01 PM, Robert Haas wrote:
>> One thing that's tricky/annoying about this is that if you have a
>> DEFAULT partition and then add a partition, you have to scan the
>> DEFAULT partition for data that should be moved to the
On Thu, Dec 8, 2016 at 3:53 AM, Srinivas Karthik V
wrote:
> Dear PostgreSQL Hackers,
>
> I am working in PostgreSQL 9.4.* optimizer module. In costsize.c file and
> final_cost_hashjoin() function, the innerbucketsize is either:
>
> a) calculated using a cached copy
>
On Thu, Dec 8, 2016 at 10:28 AM, Tom Lane wrote:
> Robert Haas writes:
> > Maybe it would help for Jeff to use elog_node_display() to the nodes
> > that are causing the problem - e.g. outerpathkeys and innerpathkeys
> > and best_path->path_mergeclauses, or just best_path - at the point
> > where
I would like to propose a patch for parallelizing merge join path.
This idea is derived by analyzing TPCH results.
I have done this analysis along with my colleagues Rafia sabih and Amit kaplia.
Currently we already have infrastructure for executing parallel join,
so we don't need any change at e
On Wed, Nov 30, 2016 at 11:08 AM, Dilip Kumar wrote:
>>
>> patch details
>> 1. hash_support_alloc_free_v1.patch [1].
>> 2. parallel-bitmap-heap-scan-v3.patch
Few assorted comments:
1.
+ else if (needWait)
+ {
+ /* Add ourself to wait queue */
+ ConditionVariablePrepareToSleep(&pbminfo->cv);
+ qu
On Thu, Dec 8, 2016 at 3:02 PM, Masahiko Sawada wrote:
> On Thu, Dec 8, 2016 at 4:39 PM, Michael Paquier
> wrote:
>> On Thu, Dec 8, 2016 at 9:07 AM, Robert Haas wrote:
>>> You could do that, but first I would code up the simplest, cleanest
>>> algorithm you can think of and see if it even shows
24 matches
Mail list logo
