Re: bad plan - Mailing list pgsql-performance

From Gaetano Mendola
Subject Re: bad plan
Date
Msg-id 422E47A0.1080008@bigfoot.com
Whole thread Raw
In response to Re: bad plan  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> Gaetano Mendola <mendola@bigfoot.com> writes:
>
>>>Since your query is so simple, I'm guessing v_sc_user_request is a view.
>>>Can you provide the definition?
>
>
>>Of course:
>
>
> I don't think you've told us the whole truth about the v_sc_packages
> view.  The definition as given doesn't work at all (it'll have
> duplicate column names), but more to the point, if it were that simple
> then the planner would fold it into the parent query.  The subquery
> scan node indicates that folding did not occur.  The most likely reason
> for that is that there's an ORDER BY in the view.

I didn't say the complete truth because the view definition is long so I just omitted
all fields.

explain analyze SELECT name,url,descr,request_status,url_status,size_mb,estimated_start,request_time_stamp
FROM v_sc_user_request
WHERE login = 'babinow1'
LIMIT 10 ;

these are the complete  definitions of views involved in the query:



CREATE OR REPLACE VIEW v_sc_user_request AS
  SELECT
      vsr.id_sat_request                                               AS id_sat_request,
      vsr.id_user                                                      AS id_user,
      vsr.login                                                        AS login,
      vsr.url                                                          AS url,
      vsr.name                                                         AS name,
      vsr.descr                                                        AS descr,
      vsr.size                                                         AS size,
      trunc(vsr.size/1024.0/1024.0,2)                                  AS size_mb,
      vsr.id_sat_request_status                                        AS id_sat_request_status,
      sp_lookup_key('sat_request_status',   vsr.id_sat_request_status) AS request_status,
      sp_lookup_descr('sat_request_status', vsr.id_sat_request_status) AS request_status_descr,
      vsr.id_url_status                                                AS id_url_status,
      sp_lookup_key('url_status',           vsr.id_url_status)         AS url_status,
      sp_lookup_descr('url_status',         vsr.id_url_status)         AS url_status_descr,
      vsr.url_time_stamp                                               AS url_time_stamp,
      date_trunc('seconds',vsr.request_time)                           AS request_time_stamp,
      vsr.id_package                                                   AS id_package,
      COALESCE(date_trunc('seconds',vsp.estimated_start)::text,'NA')   AS estimated_start

  FROM
      v_sat_request vsr LEFT OUTER JOIN v_sc_packages vsp USING ( id_package )
  WHERE
      vsr.request_time > now() - '1 month'::interval AND
      vsr.expired = FALSE
  ORDER BY id_sat_request DESC
;




CREATE OR REPLACE VIEW v_sat_request AS
  SELECT
     sr.id_user               AS id_user,
     ul.login                 AS login,
     sr.id_sat_request        AS id_sat_request,
     u.id_url                 AS id_url,
     u.url                    AS url,
     u.name                   AS name,
     u.descr                  AS descr,
     u.size                   AS size,
     u.storage                AS storage,
     sr.id_package            AS id_package,
     sr.id_sat_request_status AS id_sat_request_status,
     sr.request_time          AS request_time,
     sr.work_time             AS request_work_time,
     u.id_url_status          AS id_url_status,
     u.time_stamp             AS url_time_stamp,
     sr.expired               AS expired
  FROM
     sat_request sr,
     url         u,
     user_login  ul
  WHERE
     ---------------- JOIN ---------------------
     sr.id_url  = u.id_url AND
     sr.id_user = ul.id_user
     -------------------------------------------
;




CREATE OR REPLACE VIEW v_sc_packages AS
  SELECT

     vpr.id_program                            AS id_program,
     vpr.name                                  AS program_name,

     vpk.id_package                            AS id_package,
     date_trunc('seconds', vs.estimated_start) AS estimated_start,

     vpk.name                                  AS package_name,
     vpk.TYPE                                  AS TYPE,
     vpk.description                           AS description,
     vpk.target                                AS target,
     vpk.fec                                   AS fec_alg,
     vpk.output_group - vpk.input_group        AS fec_redundancy,
     vpk.priority                              AS priority,
     vpk.updatable                             AS updatable,
     vpk.auto_listen                           AS auto_listen,
     vpk.start_file                            AS start_file,
     vpk.view_target_group                     AS view_target_group,
     vpk.target_group                          AS target_group

  FROM
      v_programs           vpr,
      v_packages           vpk,
      v_sequences          vs

  WHERE
     ------------ JOIN -------------
      vpr.id_program = vs.id_program AND
      vpk.id_package = vs.id_package AND

     -------------------------------
      vs.estimated_start IS NOT NULL
;



CREATE OR REPLACE VIEW v_programs AS
  SELECT id_program     AS id_program,
         id_publisher   AS id_publisher,
         name           AS name,
         description    AS description,
         sp_lookup_key('program_type',   id_program_type)    AS TYPE,
         sp_lookup_key('program_status', id_program_status)  AS status,
         last_position  AS last_position
  FROM programs
  WHERE id_program<>0
;


CREATE OR REPLACE VIEW v_packages AS
  SELECT p.id_package            AS id_package,
         p.id_publisher          AS id_publisher,
         p.name                  AS name,
         p.information           AS information,
         p.description           AS description,
         sp_lookup_key('package_type', p.id_package_type)
                                 AS TYPE,
         sp_lookup_key('target', p.id_target)
                                 AS target,
         p.port                  AS port,
         p.priority              AS priority,
         sp_lookup_key('fec', p.id_fec)
                                 AS fec,
         p.input_group           AS input_group,
         p.output_group          AS output_group,
         p.updatable             AS updatable,
         p.checksum              AS checksum,
         p.version               AS version,
         p.start_file            AS start_file,
         p.view_target_group     AS view_target_group,
         p.target_group          AS target_group,
         p.auto_listen           AS auto_listen,
         p.public_flag           AS public_flag,
         p.needed_version        AS needed_version,
         p.logic_version         AS logic_version,
         p.package_size          AS package_size,
         ps.id_drm_process       AS id_drm_process,
         ps.id_cas_service       AS id_cas_service,
         ps.id_cas_settings      AS id_cas_settings,
         ps.id_drm_service       AS id_drm_service

  FROM packages p LEFT OUTER JOIN package_security ps USING (id_package)
 ;



CREATE OR REPLACE VIEW v_sequences AS
  SELECT id_package        AS id_package,
         id_program        AS id_program,
         internal_position AS internal_position,
         estimated_start   AS estimated_start
  FROM sequences
;



> Putting ORDER BYs in views that you intend to use as components of other
> views is a bad practice from a performance perspective...

Indeed when a view is involved in a join we do not put "order by" in it ( at
least this is what I try to do ), I have to say also that some time I see that replacing
the view with the tables that it represent the execution time is better
( I have an example to show you if you are interested in it ).


Regards
Gaetano Mendola





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCLkef7UpzwH2SGd4RAt90AJ9e3qUSx2fxiOO2aA30TbLsOdyV7ACfd0RY
+2A3U6dDfWw/H4eWcmI8mS0=
=t1AD
-----END PGP SIGNATURE-----


pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Why would writes to pgsql_tmp bottleneck at 1mb/s?
Next
From: Gaetano Mendola
Date:
Subject: Re: pl/pgsql faster than raw SQL?