Re: Bad plan for ltree predicate <@

2017-12-01 Thread Roman Konoval
Hi Tom, Thanks for your help. > On Dec 1, 2017, at 22:33, Tom Lane wrote: > > > The seqscan formulation of the query results in evaluating > this function afresh at most of the rows The function is defined as STABLE. I though that means that there is no need to reevaluate it on every row as

Re: Bad plan for ltree predicate <@

2017-12-01 Thread Tom Lane
Roman Konoval writes: > I have a problem on 9.3.14 with a query that accesses table: I think the root of the problem is your intermediate function: > CREATE OR REPLACE FUNCTION public.get_doc_path(document_id character varying) > RETURNS ltree > LANGUAGE plpgsql > STABLE > AS $function$ > DEC

Bad plan for ltree predicate <@

2017-12-01 Thread Roman Konoval
Hi, I have a problem on 9.3.14 with a query that accesses table: Size: (retrieved by query https://gist.github.com/romank0/74f9d1d807bd3f41c0729d0fc6126749) schemaname |relname| size | toast | associated_idx_size | total +---+++-