> You're suggesting a [d] choice, subdividing the horizontal headers.
> It seems to me like a pretty radical change, multiplying the number
> of columns, and it has also the potential to give poor results visually.
> Let's see if more feedback comes.
>
yes, I know, plan @d needs lot of new code -
On Fri, Sep 18, 2015 at 11:31 PM, Jesper Pedersen <
jesper.peder...@redhat.com> wrote:
> On 08/31/2015 07:34 AM, Amit Kapila wrote:
>
>> I have updated the patch (attached with mail) to show
>> you what I have in mind.
>>
>>
> I havn't been able to get a successful run with _v5 using pgbench.
>
>
On Fri, Sep 18, 2015 at 11:08 PM, Jesper Pedersen <
jesper.peder...@redhat.com> wrote:
> On 09/11/2015 10:31 AM, Amit Kapila wrote:
>
>> Updated comments and the patch (increate_clog_bufs_v2.patch)
>> containing the same is attached.
>>
>>
> I have done various runs on an Intel Xeon 28C/56T w/ 256
On 7/23/15 6:39 PM, Tom Lane wrote:
> + 2202HEERRCODE_INVALID_TABLESAMPLE_ARGUMENT
> invalid_tablesample_argument
> + 2202GEERRCODE_INVALID_TABLESAMPLE_REPEAT
> invalid_tablesample_repeat
Where did you get these error codes fr
On Fri, Sep 18, 2015 at 09:01:15AM -0400, Adam Brightwell wrote:
> > 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to
> > policies
>
> I believe this one has already been addressed by Stephen
> (20150910192313.gt3...@tamriel.snowman.net)? Are there further
> considerations fo
On Fri, Sep 18, 2015 at 6:25 PM, Michael Paquier wrote:
> The refactoring of getTimelineHistory as you propose looks like a good
> idea to me, I tried to remove by myself the difference between source
> and target in copy_fetch.c and friends but this gets uglier,
> particularly because of datadir_s
On Fri, Sep 18, 2015 at 12:34 PM, Michael Paquier
wrote:
> On Fri, Sep 18, 2015 at 9:00 AM, Alexander Korotkov wrote:
>> BTW, it would be an option to generate system_identifier to each new
>> timeline, by analogy of initdb do for the whole WAL.
>> Having such system_identifiers we can distinguish
On Wed, Sep 16, 2015 at 9:47 AM, Alexander Korotkov wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, Michael Paquier wrote:
> OK, I get it. I tried to get rid of code duplication in the attached patch.
> There is getTimelineHistory() function which gets control file as argument
> and fetches history from
On Fri, Sep 18, 2015 at 9:45 PM, Amit Kapila wrote:
> On Fri, Sep 18, 2015 at 1:33 PM, Haribabu Kommi
> wrote:
>>
>> On Thu, Sep 3, 2015 at 8:21 PM, Amit Kapila
>> wrote:
>> >
>> > Attached, find the rebased version of patch.
>>
>> Here are the performance test results:
>>
>> Query sele
> 18 сент. 2015 г., в 20:16, Robert Haas написал(а):
>
> On Fri, Sep 18, 2015 at 4:08 AM, Vladimir Borodin wrote:
>> For both scenarios on linux we got approximately the same results - version
>> with timings was faster then version with sampling (sampling was done every
>> 10 ms). Vanilla Post
On Fri, Sep 18, 2015 at 6:27 AM, Tom Lane wrote:
> [ moving thread to -hackers ]
>
> Fujii Masao writes:
> > So autoanalyze still doesn't call IndexFreeSpaceMapVacuum().
> > That is, only backend can clean the list in INSERT-only workload.
> > I don't think that this is desirable. Because the ba
Pavel Stehule wrote:
> 2. Data column are not well aligned - numbers are aligned as text
Thanks for spotting that, it's fixed in the attached new iteration of
the patch.
> 3. When data are multiattribute - then merging together with space separator
> is not practical
>
> * important i
On Fri, Sep 18, 2015 at 12:56 PM, Robert Haas wrote:
> On Thu, Sep 17, 2015 at 11:44 PM, Amit Kapila wrote:
>> Okay, but I think the same can be achieved with this as well. Basic idea
>> is that each worker will work on one planned statement at a time and in
>> above case there will be two diffe
-1. double is an inexact type, whereas integer is an exact type.
Sure. I already argue on that very line.
The typical way to handle this sort of thing is to define a struct
whose first member is a type field and whose second field is a union
of all the types you need to care about.
Yep.
On 08/31/2015 07:34 AM, Amit Kapila wrote:
I have updated the patch (attached with mail) to show
you what I have in mind.
I havn't been able to get a successful run with _v5 using pgbench.
TransactionIdSetStatusBit assumes an exclusive lock on CLogControlLock
when called, but that part is re
On 09/11/2015 10:31 AM, Amit Kapila wrote:
Updated comments and the patch (increate_clog_bufs_v2.patch)
containing the same is attached.
I have done various runs on an Intel Xeon 28C/56T w/ 256Gb mem and 2 x
RAID10 SSD (data + xlog) with Min(64,).
Kept the shared_buffers=64GB and effective_
On Fri, Sep 18, 2015 at 9:00 AM, Alexander Korotkov wrote:
> BTW, it would be an option to generate system_identifier to each new
> timeline, by analogy of initdb do for the whole WAL.
> Having such system_identifiers we can distinguish different timeline which
> have assigned same ids.
> Any thoug
On Fri, Sep 18, 2015 at 6:55 AM, Amit Kapila wrote:
>> +currentRelation = ExecOpenScanRelation(estate,
>> + ((SeqScan *)
>> node->ss.ps.plan)->scanrelid,
>> + eflags);
>>
>> I can't see how this can possibly be
On Fri, Sep 18, 2015 at 4:08 AM, Vladimir Borodin wrote:
> For both scenarios on linux we got approximately the same results - version
> with timings was faster then version with sampling (sampling was done every
> 10 ms). Vanilla PostgreSQL from REL9_4_STABLE gave ~15500 tps and version
> with ti
On Thu, Sep 17, 2015 at 10:58 PM, Kyotaro HORIGUCHI
wrote:
> By the way, the complexity comes from separating integer and
> double. If there is no serios reason to separate them, handling
> all values as double makes things far simpler.
-1. double is an inexact type, whereas integer is an exact
On Fri, Sep 18, 2015 at 5:24 AM, Kouhei Kaigai wrote:
>> On Thu, Sep 17, 2015 at 9:01 PM, Kouhei Kaigai wrote:
>> > I entirely agree with the idea of plan-node identifier, however,
>> > uncertain whether the node-id shall represent physical location on
>> > the dynamic shared memory segment, beca
On Fri, Sep 18, 2015 at 6:59 AM, Pavel Stehule wrote:
> I am afraid so it has not simple and nice solution - when data sender will
> wait for to moment when data are received, then we have same complexity like
> we use shm_mq.
>
> Isn't better to introduce new background worker with responsibilit
On Thu, Sep 17, 2015 at 11:44 PM, Amit Kapila wrote:
> Okay, but I think the same can be achieved with this as well. Basic idea
> is that each worker will work on one planned statement at a time and in
> above case there will be two different planned statements and they will
> store partial seq s
On Fri, Sep 18, 2015 at 12:18 AM, Euler Taveira wrote:
> Yeah, I know. [Too sleepy to be writing emails...] What I want to say is:
> when we want to refer to an option, we usually add "option" after the quoted
> name (in this case, it won't make sense). I propose to remove the quotation
> because
"David E. Wheeler" writes:
> On Sep 18, 2015, at 7:29 AM, Teodor Sigaev wrote:
>> Fixed (9acb9007de30b3daaa9efc16763c3bc6e3e0a92d), but didn't backpatch
>> because it isn't a critical bug.
> Great, thank you!
> For those on older versions, whatâs the simplest workaround?
FWIW, I thought this
On Sep 18, 2015, at 7:29 AM, Teodor Sigaev wrote:
>> Fixable?
>
> Fixed (9acb9007de30b3daaa9efc16763c3bc6e3e0a92d), but didn't backpatch
> because it isn't a critical bug.
Great, thank you!
For those on older versions, what’s the simplest workaround?
Best,
David
--
Sent via pgsql-hacker
On Fri, Sep 18, 2015 at 4:03 AM, Haribabu Kommi
wrote:
> On Thu, Sep 3, 2015 at 8:21 PM, Amit Kapila wrote:
>>
>> Attached, find the rebased version of patch.
>
> Here are the performance test results:
Thanks, this is really interesting. I'm very surprised by how much
kernel overhead this shows
В письме от 11 сентября 2015 15:12:04 Вы написали:
> > Ok.Let's come to the final decision with tuple_data_parse, and i will add
> > this switch there and to pure sql heap_page_item_attrs
>
> Fine for me.
So I've modified the code, now we have:
heap_page_items - have a column with raw tuple dat
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.
> If a specific entry is invalidated it per
Fixable?
Fixed (9acb9007de30b3daaa9efc16763c3bc6e3e0a92d), but didn't backpatch because
it isn't a critical bug.
Thank you for the report!
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.r
On 09/18/2015 09:25 AM, Adam Brightwell wrote:
>>> 1. remove row_security=force
>>> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to
>>> policies
>>> 3. add DDL-controlled, per-table policy forcing
>>>
>>> They ought to land in that order. PostgreSQL 9.5 would need at least (1
Reply to both emails in one
Fujii:
> So autoanalyze still doesn't call IndexFreeSpaceMapVacuum().
Fixed, see patch
> ginvacuumcleanup calls RecordFreeIndexPage() twice for the same block.
fixed too
Tom:
It seems quite bizarre for auto-analyze to do that. auto-vacuum, sure,
but I do not think
>> 1. remove row_security=force
>> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies
>> 3. add DDL-controlled, per-table policy forcing
>>
>> They ought to land in that order. PostgreSQL 9.5 would need at least (1) and
>> (2); would RLS experts find it beneficial for me
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On 09/18/2015 01:07 AM, Noah Misch wrote:
> Great. Robert, does that work for you, too? If so, this sub-thread is
> looking at three patches:
>
> 1. remove row_security=force
> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies
> 3. add DDL-controlled, per-table policy
On Wed, Sep 16, 2015 at 7:47 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> On Wed, Sep 9, 2015 at 7:13 PM, Alexander Korotkov wrote:
>
> > A also added additional check in findCommonAncestorT
On Fri, Sep 18, 2015 at 2:07 AM, Noah Misch wrote:
> On Tue, Sep 15, 2015 at 03:18:21PM -0400, Adam Brightwell wrote:
>> On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway wrote:
>> >> Joe Conway writes:
>> >>> There are use cases where row_security=force will be set in production
>> >>> environments,
[ moving thread to -hackers ]
Fujii Masao writes:
> So autoanalyze still doesn't call IndexFreeSpaceMapVacuum().
> That is, only backend can clean the list in INSERT-only workload.
> I don't think that this is desirable. Because the backend will
> periodically take a big performance penalty.
> S
> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies
I believe this one has already been addressed by Stephen
(20150910192313.gt3...@tamriel.snowman.net)? Are there further
considerations for his proposed changes?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydat
2015-09-18 13:59 GMT+02:00 Daniel Verite :
> Pavel Stehule wrote:
>
>
> > my comments:
> >
> > 1. I don't understand why you are use two methods for sorting columns
> > (qsort, and query with ORDER BY)
>
> qsort (with strcmp as the comparator) is only used to determine the
> set of distinc
On Thu, Sep 17, 2015 at 4:44 PM, Robert Haas wrote:
> On Thu, Sep 17, 2015 at 2:54 AM, Amit Kapila
wrote:
>
>
> > Here the subplan is generated before the top level plan and while
generation
> > of subplan we can't predict whether it is okay to generate it as Funnel
or
> > not,
> > because it mig
On Thu, Sep 17, 2015 at 12:47 PM, Shulgin, Oleksandr
wrote:
> But if we make the sender backend create the DSM with the response payload,
> it suddenly becomes really unclear at which point and who should make the
> final detach of that DSM. We're getting back to the problem of
> synchronization
Pavel Stehule wrote:
> my comments:
>
> 1. I don't understand why you are use two methods for sorting columns
> (qsort, and query with ORDER BY)
qsort (with strcmp as the comparator) is only used to determine the
set of distinct values for the vertical and horizontal headers.
In fact th
2015-09-18 13:36 GMT+02:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > in the help inside your last patch, you are using "crosstab". Cannto be
> > crosstab the name for this feature?
>
> If it wasn't taken already by contrib/tablefunc, that would be a first
> choice. But now, when searchi
On Fri, Sep 18, 2015 at 1:33 PM, Haribabu Kommi
wrote:
> On Thu, Sep 3, 2015 at 8:21 PM, Amit Kapila
> wrote:
> >
> > Attached, find the rebased version of patch.
>
> Here are the performance test results:
>
> Query selectivityHashAgg HashAgg
>
Pavel Stehule wrote:
> in the help inside your last patch, you are using "crosstab". Cannto be
> crosstab the name for this feature?
If it wasn't taken already by contrib/tablefunc, that would be a first
choice. But now, when searching for crosstab+postgresql, pages of
results come out co
2015-09-18 13:22 GMT+02:00 Shulgin, Oleksandr
:
> On Fri, Sep 18, 2015 at 12:59 PM, Pavel Stehule
> wrote:
>
>> 2015-09-18 12:05 GMT+02:00 Shulgin, Oleksandr <
>> oleksandr.shul...@zalando.de>:
>>
>>> On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule >> > wrote:
>>>
It should not be true
On Fri, Sep 18, 2015 at 12:59 PM, Pavel Stehule
wrote:
> 2015-09-18 12:05 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
>> On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule
>> wrote:
>>
>>>
>>> It should not be true - the data sender create DSM and fills it. Then
>>> set caller
On Fri, Sep 18, 2015 at 6:13 PM, Fujii Masao wrote:
> On Fri, Sep 4, 2015 at 2:55 PM, Masahiko Sawada wrote:
>> On Fri, Sep 4, 2015 at 10:35 AM, Fujii Masao wrote:
>>> On Fri, Sep 4, 2015 at 2:23 AM, Masahiko Sawada
>>> wrote:
On Thu, Aug 27, 2015 at 1:54 AM, Masahiko Sawada
wrote:
2015-09-18 12:05 GMT+02:00 Shulgin, Oleksandr
:
> On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule
> wrote:
>
>> 2015-09-18 10:59 GMT+02:00 Shulgin, Oleksandr <
>> oleksandr.shul...@zalando.de>:
>>
>>>
>>> If we take the per-backend slot approach the locking seems unnecessary
>>> and there are pr
On Thu, Sep 17, 2015 at 2:28 AM, Robert Haas wrote:
>
> On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila
wrote:
> +/*
> + * We expect each worker to populate the BufferUsage structure
> + * allocated by master backend and then master backend will aggregate
> + * all the usage along wit
On Fri, Sep 18, 2015 at 7:06 PM, Kyotaro HORIGUCHI
wrote:
> Hello, I have some random comments.
Thanks for the feedback! I have fixed several of the things that you
found in the attached new version -- see comments inline below.
However, I now know that Simon has a better patch in development to
On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule
wrote:
> 2015-09-18 10:59 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
>>
>> If we take the per-backend slot approach the locking seems unnecessary
>> and there are principally two options:
>>
>> 1) The backend puts the DSM hand
Hello,
[...] If you make the sorting criterion include the tablespace id you
wouldn't need the lookahead loop in NextBufferToWrite().
I'm considering this precise point, i.e. including the tablespace as
a sorting criterion.
Currently the array used for sorting is 16 bytes per buffer (althoug
2015-09-18 10:59 GMT+02:00 Shulgin, Oleksandr
:
> On Thu, Sep 17, 2015 at 10:13 PM, Robert Haas
> wrote:
>
>> On Thu, Sep 17, 2015 at 11:16 AM, Pavel Stehule
>> wrote:
>>
>> >> Second, using a shm_mq manipulates the state of the process latch. I
>> >> don't think you can make the assumption th
> On Thu, Sep 17, 2015 at 9:01 PM, Kouhei Kaigai wrote:
> > I entirely agree with the idea of plan-node identifier, however,
> > uncertain whether the node-id shall represent physical location on
> > the dynamic shared memory segment, because
> > (1) Relatively smaller number of node type needs sh
On Fri, Sep 4, 2015 at 2:55 PM, Masahiko Sawada wrote:
> On Fri, Sep 4, 2015 at 10:35 AM, Fujii Masao wrote:
>> On Fri, Sep 4, 2015 at 2:23 AM, Masahiko Sawada
>> wrote:
>>> On Thu, Aug 27, 2015 at 1:54 AM, Masahiko Sawada
>>> wrote:
On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera
On Thu, Sep 17, 2015 at 10:13 PM, Robert Haas wrote:
> On Thu, Sep 17, 2015 at 11:16 AM, Pavel Stehule
> wrote:
>
> >> Second, using a shm_mq manipulates the state of the process latch. I
> >> don't think you can make the assumption that it's safe to reset the
> >> process latch at any and ever
Hello Kyotaro-san,
My description should have been obscure. Indeed the call tree is
finite for *sane* expression node. But it makes infinit call for
a value of expr->etype unknown by both evalDouble and
evalInt.
Such issue would be detected if the function is actually tested, hopefully
this
> 16 сент. 2015 г., в 20:52, Robert Haas написал(а):
>
> On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov
> wrote:
>> Yes, the major question is cost. But I think we should validate our thoughts
>> by experiments assuming there are more possible synchronization protocols.
>> Ildus posted im
3. When data are multiattribute - then merging together with space
> separator is not practical
>
> * important information is lost
> * same transformation can be done as expression, so this feature is
> useless
>
> Is possible to use one cell per attribute (don't do merge)?
>
> DATA QUERY: SEL
Hello, I have some random comments.
At Wed, 16 Sep 2015 23:07:03 +1200, Thomas Munro
wrote in
> On Tue, Sep 8, 2015 at 1:11 AM, Thomas Munro
> wrote:
>
> > On Thu, Sep 3, 2015 at 12:02 AM, Fujii Masao
> > wrote:
> > Hmm. So maybe commit records could have a flag saying 'someone is waiting
62 matches
Mail list logo
