| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, ivan(dot)marchesini(at)gmail(dot)com, pgsql-general(at)postgresql(dot)org, Mauro Rossi <mauro(dot)rossi(at)irpi(dot)cnr(dot)it> |
| Subject: | Re: difference in query performance due to the inclusion of a polygon geometry field |
| Date: | 2012-11-30 16:12:36 |
| Message-ID: | CAHyXU0xUxwM6UVqP0vx3wMjT0rk4BKis9QYTBKviJweJg8s5og@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Nov 30, 2012 at 9:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> writes:
>> As I said -- could the time be spent on the client?
>
> It is probably some combination of
>
> (1) time to fetch the wide geometry values from the table's TOAST table
> (2) time to convert the geometry values to text form
> (3) time to transmit the larger volume of data to the client
> (4) client-side processing time
>
> None of these costs are expended in an EXPLAIN ANALYZE, which is
> why the time reported for that doesn't change materially.
Also possibly decompression time too.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ivan Marchesini | 2012-11-30 16:30:44 | Re: difference in query performance due to the inclusion of a polygon geometry field |
| Previous Message | Tom Lane | 2012-11-30 15:51:50 | Re: difference in query performance due to the inclusion of a polygon geometry field |