I am using PostgreSQL 10 on windows 7 (64 bit) machine.I have a PostgreSQL table whose structure is given below.

CREATE TABLE public.linedata
(
    linedataid bigint NOT NULL,
    customerid integer NOT NULL,
    linelatlong geometry(LineString,4326),
    createdon date DEFAULT now()
)
WITH (
    OIDS = FALSE
)
TABLESPACE pg_default;

ALTER TABLE public.linedata
    OWNER to postgres;

CREATE INDEX idx_linedata_customerid
    ON public.linedata USING btree
    (customerid)
    TABLESPACE pg_default;



CREATE INDEX idx_linedata_linedataid
    ON public.linedata USING btree
    (linedataid)
    TABLESPACE pg_default;


CREATE INDEX idx_linedata_geom
    ON public.linedata USING gist
    (linelatlong)
    TABLESPACE pg_default;

This table has 4333053 records. Geoserver call this table to get data and render layers. But the performance is very slow. Geoserver uses below given query.

Select pgis.linelatlong
From public.linedata as pgis 
INNER JOIN
public.tempLine as tdp ON tdp.templineid=pgis.linedataid
where tdp.uniquedata=%drivepathid%
AND pgis.linelatlong is not null

structure of templine table is given below.


CREATE TABLE public.tempLine
(
    templineid bigint,
    uniquedata bigint
)
WITH (
    OIDS = FALSE
)
TABLESPACE pg_default;

ALTER TABLE public.tempLine
    OWNER to postgres;

    CREATE INDEX idx_tempLine_uniquedata
    ON public.tempLine USING btree
    (uniquedata)
    TABLESPACE pg_default;

drivepathid is a viewparams. In the LineData table linedataid can be duplicate for a customer therefore did not set it as primary key.LineData table is populated from some external source. The above query returns 14652 records only and took 4-5 minutes. AutoVaccum and AutoAnalyze is set on this table.

Explain analyze and query is given below.

Select pgis.linelatlong
From public.linedata as pgis 
INNER JOIN
public.tempLine as tdp ON tdp.templineid=pgis.linedataid
where tdp.uniquedata=1711058674182521921
AND pgis.linelatlong is not null
"Gather  (cost=1000.43..226588.94 rows=50881 width=6588) (actual time=0.555..525.171 rows=14652 loops=1)"
"  Workers Planned: 2"
"  Workers Launched: 2"
"  ->  Nested Loop  (cost=0.43..220500.84 rows=21200 width=6588) (actual time=250.457..425.718 rows=4884 loops=3)"
"        ->  Parallel Seq Scan on tempLine tdp  (cost=0.00..121612.47 rows=6525 width=8) (actual time=250.411..415.384 rows=4884 loops=3)"
"              Filter: (uniquedata = '1711058674182521921'::bigint)"
"              Rows Removed by Filter: 3814396"
"        ->  Index Scan using idx_linedata_linedataid on linedata pgis  (cost=0.43..15.13 rows=3 width=6596) (actual time=0.002..0.002 rows=1 loops=14652)"
"              Index Cond: (drivepathid = tdp.drivepathid)"
"Planning time: 0.256 ms"
"Execution time: 530.261 ms"
Another query 
Select pgis.linelatlong
From public.linedata as pgis 
INNER JOIN
public.tempLine as tdp ON tdp.templineid=pgis.linedataid
where tdp.uniquedata=1712927718674269255 and customerid=2
'Nested Loop  (cost=0.87..20.82 rows=1 width=6588) (actual time=0.066..867.672 rows=384339 loops=1)'
'  ->  Index Scan using idx_tempLine_uniquedata on tempLine tdp  (cost=0.44..4.45 rows=1 width=8) (actual time=0.047..72.414 rows=378959 loops=1)'
'        Index Cond: (uniquedata = '1712927718674269255'::bigint)'
'  ->  Index Scan using idx_linedata_linedataid on linedata pgis  (cost=0.43..16.36 rows=1 width=6596) (actual time=0.002..0.002 rows=1 loops=378959)'
'        Index Cond: (drivepathid = tdp.drivepathid)'
'        Filter: (customerid = 2)'
'Planning time: 5.642 ms'
'Execution time: 880.412 ms'

Any Suggestion ?

migrated from gis.stackexchange.com Feb 12 at 5:03

This question came from our site for cartographers, geographers and GIS professionals.

  • Is this a PostgreSQL performance issue that should be researched at the Database Administrators Stack Exchange or a PostGIS performance issue that is on-topic here? – PolyGeo Feb 12 at 4:56
  • PolyGeo you are right. This is a PostgreSQL performance issue and I should copy this to Database Administrators stack exchange. However, if you have any idea, tell me. – M.Sharma Feb 12 at 5:01
  • I'll migrate it to save you copying and deleting. – PolyGeo Feb 12 at 5:02
  • The execution plan shows the query only takes half a second, not 5 minutes – a_horse_with_no_name Feb 12 at 6:33
  • 1
    Please edit your question and add the plan there instead of as a comment. – McNets Feb 12 at 8:17

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.