And if it helps,
see below results of my explain(analyze, buffers) where it is worse on
9.2.1 than on 9.1.4 (both on the same hardware):
Original view:
pg 9.1.4:
Nested Loop (cost=237.46..289.36 rows=1 width=254) (actual
time=3998.609..5870.697 rows=1848 loops=1)
Buffers: shared hit=1044261 re
I was doing the test on the released 9.2.1 (without the patch).
The times of the query with the original view were floating around those
values, so it's maybe just a luck that it was slightly slower on 9.2.1.
The big difference was after the view was restored with the explicit
cast. The purpose of
Vaclav Juza writes:
> I have modified the test case (it is more similar to the real-word
> query), so that now it is slower on 9.2.1 than on 9.1.4 (the version
> with the explicit cast):
FWIW, testing this on HEAD (with the patch I committed last week),
I get a plan that's about 10% faster than 9
On 12/10/2012 23:24, Tom Lane wrote:
> vaclav.j...@xitee.com writes:
>
>> In the real case we faced this problem, the performance loss was much higher
>> on PostgreSQL 9.2.1 (3 seconds vs. 3 minutes) than on 9.1.4 (1.3 seconds vs.
>> 7 seconds) and both variants were slower on 9.2.1 than on 9.1.4.
vaclav.j...@xitee.com writes:
> when a view (with the below properites) is dump and restored (no matter if
> using pg_dump, copied from pg_admin or using pg_views) it's performance is
> worse than before. The view was using tables with columns of type "character
> varying(xx)" and the dump inserts
The following bug has been logged on the website:
Bug reference: 7598
Logged by: Vaclav Juza
Email address: vaclav.j...@xitee.com
PostgreSQL version: 9.2.1
Operating system: Linux 2.6.18-128.el5 x86_64 (RHEL 5.3)
Description:
Hi,
when a view (with the below properites
