2015-12-23 21:36 GMT+01:00 Daniel Verite :
>Hi,
>
> Here's an updated patch that replaces sorted arrays by AVL binary trees
> when gathering distinct values for the columns involved in the pivot.
> The change is essential for large resultsets. For instance,
> it allows to process a query like
brin_summarize_new_values() does not check that it is called on the
correct type of index, nor does it check permissions.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund writes:
> There's a couple solutions I can think of to that problem:
> 1) Use epoll()/kqueue, or other similar interfaces that don't require
>re-registering fds at every invocation. My guess is that that'd be
>desirable for performance anyway.
Portability, on the other hand,
On 2015-12-25 13:28:55 -0500, Tom Lane wrote:
> Hmm. And all those FDs point to the same pipe. I wonder if we're looking
> at contention for some pipe-related data structure inside the kernel.
Sounds fairly likely - and not too surprising. In this scenario we've a
couple 100k registrations/unreg
On Thu, Dec 24, 2015 at 09:45:40PM +0900, Michael Paquier wrote:
> On Thu, Dec 24, 2015 at 12:09 PM, Michael Paquier
> wrote:
> > On Tue, Dec 22, 2015 at 10:45 PM, Michael Paquier
> > wrote:
> >> On Tue, Dec 22, 2015 at 4:04 PM, Michael Paquier
> >> wrote:
> >>> OK, if those don't get addressed
2015-12-25 22:42 GMT+03:00 Васильев Дмитрий :
>
>
>
> 2015-12-25 21:28 GMT+03:00 Tom Lane :
>
>> Andres Freund writes:
>> > On December 25, 2015 7:10:23 PM GMT+01:00, Tom Lane
>> wrote:
>> >> Seems like what you've got here is a kernel bug.
>>
>> > I wouldn't go as far as calling it a kernel
2015-12-25 21:28 GMT+03:00 Tom Lane :
> Andres Freund writes:
> > On December 25, 2015 7:10:23 PM GMT+01:00, Tom Lane
> wrote:
> >> Seems like what you've got here is a kernel bug.
>
> > I wouldn't go as far as calling it a kernel bug. Were still doing 300k
> tps. And were triggering the perfo
Andres Freund writes:
> On December 25, 2015 7:10:23 PM GMT+01:00, Tom Lane
> wrote:
>> Seems like what you've got here is a kernel bug.
> I wouldn't go as far as calling it a kernel bug. Were still doing 300k tps.
> And were triggering the performance degradation by adding another socket
> (
On December 25, 2015 7:10:23 PM GMT+01:00, Tom Lane wrote:
>=?UTF-8?B?0JLQsNGB0LjQu9GM0LXQsiDQlNC80LjRgtGA0LjQuQ==?=
> writes:
>> ��� Samples: 1M of event 'cycles', Event count (approx.):
>816922259995, UID:
>> pgpro
>> Overhead Shared Object Symbol
>
>> 69,72% [kernel][k]
=?UTF-8?B?0JLQsNGB0LjQu9GM0LXQsiDQlNC80LjRgtGA0LjQuQ==?=
writes:
> â Samples: 1M of event 'cycles', Event count (approx.): 816922259995, UID:
> pgpro
> Overhead Shared Object Symbol
> 69,72% [kernel][k] _raw_spin_lock_irqsave
> 1,43% postgres[.] _bt_compa
Amit Langote writes:
> I wonder if the following error detail text could say more than it does
> currently for the following rather artificial example case:
> CREATE TABLE p1(a char(3));
> CREATE TABLE p2(a char(2));
> CREATE TABLE c(d int) INHERITS (p1, p2);
> NOTICE: merging multiple inherite
2015-12-25 20:44 GMT+03:00 Andres Freund :
> On December 25, 2015 6:27:06 PM GMT+01:00, "Васильев Дмитрий"
> >>If so, could you provide a hierarchical before/after profile?
> >
> >Performance | Git hash commit| Date
> >~ 360k tps | c3e7c24a1d60dc6ad56e2a0723399f1570c54224 | Thu Nov 12
> >0
On December 25, 2015 6:27:06 PM GMT+01:00, "Васильев Дмитрий"
>>If so, could you provide a hierarchical before/after profile?
>
>Performance | Git hash commit| Date
>~ 360k tps | c3e7c24a1d60dc6ad56e2a0723399f1570c54224 | Thu Nov 12
>09:12:18
>2015 -0500
>~ 360k tps | ac1d7945f866b1928c2554c
2015-12-25 20:27 GMT+03:00 Васильев Дмитрий :
>
> 2015-12-25 20:18 GMT+03:00 Andres Freund :
>
>> On December 25, 2015 6:08:15 PM GMT+01:00, "Васильев Дмитрий" <
>> d.vasil...@postgrespro.ru> wrote:
>> >Hello hackers!
>> >
>> >I suddenly found commit ac1d794 gives up to 3 times performance
>> >deg
2015-12-25 20:18 GMT+03:00 Andres Freund :
> On December 25, 2015 6:08:15 PM GMT+01:00, "Васильев Дмитрий" <
> d.vasil...@postgrespro.ru> wrote:
> >Hello hackers!
> >
> >I suddenly found commit ac1d794 gives up to 3 times performance
> >degradation.
> >
> >I tried to run pgbench -s 1000 -j 48 -c 4
On December 25, 2015 6:08:15 PM GMT+01:00, "Васильев Дмитрий"
wrote:
>Hello hackers!
>
>I suddenly found commit ac1d794 gives up to 3 times performance
>degradation.
>
>I tried to run pgbench -s 1000 -j 48 -c 48 -S -M prepared on 70
>CPU-core
>machine:
>commit ac1d794 gives me 363,474 tps
>and pr
Hello hackers!
I suddenly found commit ac1d794 gives up to 3 times performance degradation.
I tried to run pgbench -s 1000 -j 48 -c 48 -S -M prepared on 70 CPU-core
machine:
commit ac1d794 gives me 363,474 tps
and previous commit a05dc4d gives me 956,146
and master( 3d0c50f ) with revert ac1d794
Hi,
Please find attached patch addressing following comments.
>The relation OID should be reported and not its name. In case of a
>relation rename that would not be cool for tracking, and most users
>are surely going to join with other system tables using it.
The relation OID is reported instead o
On 25 December 2015 at 19:45, Michael Paquier
wrote:
> On Thu, Dec 24, 2015 at 5:57 PM, Dave Page wrote:
> > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer
> wrote:
> >> On 22 December 2015 at 23:48, Alex Ignatov
> wrote:
> >>
> >>>
> >>> I think that you can debug crash dump since windbg exist
On Thu, Dec 24, 2015 at 5:57 PM, Dave Page wrote:
> On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer wrote:
>> On 22 December 2015 at 23:48, Alex Ignatov wrote:
>>
>>>
>>> I think that you can debug crash dump since windbg exists.
>>
>>
>> Nobody in their right mind uses windbg though. Visual Studi
On Fri, Dec 25, 2015 at 5:20 AM, Gavin Flower
wrote:
> On 25/12/15 01:45, Michael Paquier wrote:
> [...]
>>
>> And the CF is no closed. Here is the final score:
>> Committed: 30.
>> Moved to next CF: 42.
>> Rejected: 9.
>> Returned with Feedback: 22.
>> Total: 103.
>> Regards,
>
>
> You didn't say
On Fri, 25 Dec 2015 13:34:25 +0300
Teodor Sigaev wrote:
> Thank you, but I have some notices about
> static float
> uuid_parts_distance(pg_uuid_t *a, pg_uuid_t *b)
> {
> pg_uuid_t ua, ub;
> const double mp = pow(2, -64);
>
> uuid_cnv(a, &ua);
> uuid_cnv(b, &ub);
>
> Ass
Thank you, but I have some notices about
static float
uuid_parts_distance(pg_uuid_t *a, pg_uuid_t *b)
{
pg_uuid_t ua, ub;
const double mp = pow(2, -64);
uuid_cnv(a, &ua);
uuid_cnv(b, &ub);
Assert(ua.v64[0] > ub.v64[0]);
uint64 high = ua.v64[0] - ub.v64[0];
uint64 low
Good catch, committed.
Fornaroli Christophe wrote:
Hi,
I think that we can improve the gin index scan performance for similarity search
defined in the pg_trgm extension. The similarity function is (for the default
case where DIVUNION is defined in the code):
count / (len1 + len2 - cou
On 2015/12/24 4:34, Robert Haas wrote:
On Wed, Dec 23, 2015 at 5:50 AM, Rushabh Lathia
wrote:
+1.
I like idea of separate FDW API for the DML Pushdown. Was thinking can't we
can re-use the IterateForeignScan(ForeignScanState *node) rather then
introducing IterateDMLPushdown(ForeignScanState *
25 matches
Mail list logo
