Q:

pgAdmin slow when displaying data?

I am seeing a huge degradation in performance after moving some tables from SQL Server 2008 to Postgres, and I'm wondering if I'm missing a configuration step, or it is normal for postgres to behave this way.
The query used is a simple SELECT from the table. No joins, no ordering, nothing.
The table itself has only about 12K rows.
I have tried this on 3 machines:

Machine A hardware: 50GB RAM, SSD disks, CPU: Xeon® E5-2620v3 (OS:
Ubuntu Server 16), DBMS: Postgres 9.5 
Machine B hardware: 8GB RAM, Sata disks, CPU: Xeon E5-4640 (OS:
Ubuntu Server 12), DBMS: Postgres 9.4
Machine C hardware: 4GB RAM, IDE disks, CPU: Xeon E3-1220v2 (OS:
Windows Server 2008), DBMS: SQL Server 2008 R2

The performance I am seeing is similar between the 2 Postgres databases, despite the vast difference in hardware and configuration. How can this be?
Machine A query. Notice that I'm excluding the geometry column in order to work with "pure" datatypes:
EXPLAIN ANALYZE VERBOSE SELECT id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, 
       perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, 
       xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY"
  FROM public."korydallos_Land_Uses";

Results:
"Seq Scan on public."korydallos_Land_Uses"  (cost=0.00..872.41 rows=12841 width=209) (actual time=0.025..13.450 rows=12841 loops=1)"
"  Output: id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY""
"Planning time: 0.137 ms"
"Execution time: 14.788 ms"

This is 14 seconds for a simple select!! Wtf? Compare this with SQL Server:
Query Profile Statistics    
  Number of INSERT, DELETE and UPDATE statements    0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements   1
  Rows returned by SELECT statements    12840
  Number of transactions    0
Network Statistics  
  Number of server roundtrips   1
  TDS packets sent from client  1
  TDS packets received from server  1040
  Bytes sent from client    1010
  Bytes received from server    2477997
Time Statistics 
  Client processing time    985
  Total execution time  1022
  Wait time on server replies   37

I am at a loss at what could be happening. I also tried:

Checking for dead rows: 0
Vacuuming
Simply querying the primary key (!). This takes 500ms to execute.
With each column I add to the select, around 500 more ms are added to
the query.

Machine A Postgres performance settings:
max_connections = 200
shared_buffers = 12800MB
effective_cache_size = 38400MB
work_mem = 32MB
maintenance_work_mem = 2GB
min_wal_size = 4GB
max_wal_size = 8GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500

Machine B Postgres performance settings:
max_connections = 200
shared_buffers = 128MB
#effective_cache_size = 4GB
#work_mem = 4MB
#maintenance_work_mem = 64MB
#min_wal_size = 80MB
#max_wal_size = 1GB
#checkpoint_completion_target = 0.5
#wal_buffers = -1
#default_statistics_target = 100

Table definition in Postgres:
CREATE TABLE public."korydallos_Land_Uses"
(
  id integer NOT NULL DEFAULT nextval('"korydallos_Land_Uses_id_seq"'::regclass),
  wkb_geometry geometry(Polygon,4326),
  "OID" integer,
  type character varying(255),
  name character varying(255),
  orofos character varying(255),
  xrisi_orofoy character varying(255),
  area_sqm numeric,
  perimeter_m numeric,
  syn1_ numeric,
  syn1_id numeric,
  str_name character varying(255),
  str_no character varying(255),
  katanomh numeric,
  linkc numeric,
  xrcode character varying(255),
  kat numeric,
  ot character varying(255),
  use character varying(255),
  syn numeric,
  notes character varying(255),
  "MinX" numeric,
  "MinY" numeric,
  "MaxX" numeric,
  "MaxY" numeric,
  CONSTRAINT "korydallos_Land_Uses_pkey" PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public."korydallos_Land_Uses"
  OWNER TO root;

CREATE INDEX "sidx_korydallos_Land_Uses_wkb_geometry"
  ON public."korydallos_Land_Uses"
  USING gist
  (wkb_geometry);

EDIT: Removed the irrelevant SQL Server definition as suggested in the comments. Keeping the time as I think it's still relevant.
As per the comments, more info using:
explain (analyze, verbose, buffers, timing) SELECT id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, 
       perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, 
       xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY"
  FROM public."korydallos_Land_Uses"

Results:
"Seq Scan on public."korydallos_Land_Uses"  (cost=0.00..872.41 rows=12841 width=209) (actual time=0.019..11.207 rows=12841 loops=1)"
"  Output: id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY""
"  Buffers: shared hit=744"
"Planning time: 1.073 ms"
"Execution time: 12.269 ms"

PG Admin shows me this in the "Explain tab":
 
How I measure the 14 seconds:
Status window of PG Admin 3, bottom right corner, when running the query. (It says 14.3 secs for the trolls here).

A:

https://www.postgresql.org/docs/current/static/using-explain.html

Note that the “actual time” values are in milliseconds of real time,

so in your case 

actual time=0.019..11.207

means running query took 11 milliseconds. 
pgadmin "explain tab" says the same... Now if you see 14.3 sec in right bottom corner and the time it took is indeed 14 seconds (measured with watches) I assume it is some awful delay on network level or pgadmin itself. Try running this in psql for instance:
select clock_timestamp(); 
explain analyze select * FROM public."korydallos_Land_Uses"; 
select clock_timestamp();

this will show time intervals server side + time needed to send command from psql to server  - if it takes still 14 seconds - talk to you network admin, if not, try upgrading pgadmin

