I think I am correct in saying that the first (inner most) join is the
problem.
All the actual time is spent running this nested loop.
It does a single sequential scan of the m_transaction table (takes
about 1 second) filtering out all the m_transaction records that match
your criteria (28936
On Thursday, January 03, 2013 9:56 PM Jose Martinez wrote:
>Hi,
>I made some changes to postgresql.conf and I want them to take effect
without having to restart the server.
>I tried
>select pg_reload_conf();
>/usr/pgsql-9.1/bin/pg_ctl reload
>but when I do 'show all', I see no changes take eff
Jerome writes:
> I have a postgresql 9.1 in my server,And here 's my query,It costs
> 944,319.072 ms,it is so slow,query result have 27 records.
It looks to me like your problem is here:
> -> Seq Scan on
> m_transaction (cost=0.00..188132.06 rows
I have been experiencing spooky behavior with Postgres after using the Mac
installer for Postgres. There seems to be an existing half-baked Postgres
installation that was already there and remains there after I deleted the
Mac GUI installer version from /Applications and /Library. Part of the
spook
Jonathan Hayward writes:
> I have been experiencing spooky behavior with Postgres after using the Mac
> installer for Postgres. There seems to be an existing half-baked Postgres
> installation that was already there and remains there after I deleted the
> Mac GUI installer version from /Applicatio
Hello-
I have a large Postgres database on Ubuntu 12 (+100GB). I have an old,
SATA-based, spinning drive and a new SSD drive. I mainly do data analysis
on Postgres (big, ugly select statements). I see a few options:
1. SSD for data and OS. Spinning for temp space.
2. SSD for data. Spinning
