On Sun, May 1, 2016 at 10:27 PM, drum.lu...@gmail.com
wrote:
> Sorry @Melvin, sent the previous email just to you..
>
>
> That's a great one, too! Cheers!
>
>
> Well.. the index creation did not help...
>
> if possible please have a look on the explain analyze results:
>
> http://explain.depesz.c
Sorry @Melvin, sent the previous email just to you..
That's a great one, too! Cheers!
Well.. the index creation did not help...
if possible please have a look on the explain analyze results:
http://explain.depesz.com/s/rHOU
What else can I do?
*The indexes I created is:*
- CREATE INDEX CONC
On Sun, May 1, 2016 at 9:18 PM, drum.lu...@gmail.com
wrote:
> To clarify, the index is based on a function called "split_part()
>> The WHERE clause is only referencing the full_part column, so the planner
>> cannot associate the index with the full_part column.
>>
>
> Thanks for the explanati
>
> To clarify, the index is based on a function called "split_part()
> The WHERE clause is only referencing the full_part column, so the planner
> cannot associate the index with the full_part column.
>
Thanks for the explanation, Melvin.
It would be simple like:
CREATE INDEX CONCURRENTLY O
On Sun, May 1, 2016 at 6:31 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sunday, May 1, 2016, Melvin Davidson wrote:
>
>>
>> Your index is based on split_part function
>> but the WHERE clause is specific to full_path, so the planner cannot find
>> a valid index
>>
>>
>
>
> Davi
On Sunday, May 1, 2016, Melvin Davidson wrote:
>
> Your index is based on split_part function
> but the WHERE clause is specific to full_path, so the planner cannot find
> a valid index
>
>
This sentence is even less useful than the questions that you asked...
David J.
On Sun, May 1, 2016 at 5:58 PM, drum.lu...@gmail.com
wrote:
>
>>
>> Well, a little more information would be useful like:
>>
>
> Ops.. yes sure.. sorry about that.
>
>
>> 1. What is the PostgreSQL version?
>>
>
> PostgreSQL 9.2
>
>
>> 2. What is the O/S?
>>
>
> Linux Centos 6.7 64 bits
>
>
>> 3.
>
>
>
> Well, a little more information would be useful like:
>
Ops.. yes sure.. sorry about that.
> 1. What is the PostgreSQL version?
>
PostgreSQL 9.2
> 2. What is the O/S?
>
Linux Centos 6.7 64 bits
> 3. What is the structure of gorfs.inode_segments?
>
Table inode_segments: (I'll leave
On Sunday, May 1, 2016, drum.lu...@gmail.com wrote:
> Hi all,
>
> I've got the following index on the gorfs.inode_segments table:
>
>>
>> CREATE INDEX ix_clientids
>> ON gorfs.inode_segments
>> USING btree
>> (("split_part"("full_path"::"text", '/'::"text", 4)::integer))
>> WHERE "gorfs".
On Sun, May 1, 2016 at 5:40 PM, drum.lu...@gmail.com
wrote:
> Hi all,
>
> I've got the following index on the gorfs.inode_segments table:
>
>>
>> CREATE INDEX ix_clientids
>> ON gorfs.inode_segments
>> USING btree
>> (("split_part"("full_path"::"text", '/'::"text", 4)::integer))
>> WHERE
Hi all,
I've got the following index on the gorfs.inode_segments table:
>
> CREATE INDEX ix_clientids
> ON gorfs.inode_segments
> USING btree
> (("split_part"("full_path"::"text", '/'::"text", 4)::integer))
> WHERE "gorfs"."is_kaminski_note_path"("full_path"::"text");
And I'm running th
No, it is within the individual json object storage. In a way, it would be
part of query plan,
but strictly for the individual json object storage structure, it is not
necessarily an "index"
one possible(but primitive) implementation could be like having multiple
"segments" in the storage,
all keys
On Sun, May 1, 2016 at 6:46 AM, Tom Smith wrote:
> Hello:
>
> I'd like to bring this JSONB performance issue again.
> Below is a link of MySQL way of storing/retrieving Json key/value
>
> https://dev.mysql.com/doc/refman/5.7/en/json.html
>
> Instead of providing column indexing(like GIN for JSONB
>> On Sat, Apr 30, 2016 at 1:38 AM, wrote:
>> > I have a table with a row update trigger that is quite slow.
>> > The trigger finction basically sets some bits in a "changed" column
>> > depending on which values really changed.
>> > For some bulk updates it can be determined in advance that the
>> On 2016-04-30 02:08, wolfg...@alle-noten.de wrote:
>> > Hi,
>> >
>> > I have a table with a row update trigger that is quite slow.
>> > The trigger finction basically sets some bits in a "changed" column
>> > depending on which values really changed.
>> > For some bulk updates it can be determi
Disclaimer: My comments here are generic to Windows services.
I don't run Postgresql on Windows and I have no idea how it is
implemented.
On Sun, 1 May 2016 03:35:44 +0100, Tom Hodder
wrote:
>I've got several machines running windows 7 which have postgresql 9.4
>installed as a service, a
16 matches
Mail list logo
