Agreed. But when Tom pointed out the problem in your query you were
quite sure you couldn't be wrong. When I asked you to run explain to
see what kind of row estimate you got, I got no answer. This was a
query problem not a hardware tuning problem.
The best step for getting a good answer
Tim Uckun wrote:
I asked a question and the first reply was really snarky and unhelpful.
It's unfortunate that the first response you got was that message from
Gary Chambers, which was a bit unprofessional and started the whole
thread off in a bad direction for you. As what I've seen of
It's unfortunate that the first response you got was that message from Gary
Chambers, which was a bit unprofessional and started the whole thread off in
a bad direction for you. As what I've seen of Gary's posts suggests he is
trying to be helpful but has a quirky sense of humor, I think that
On Wed, Oct 20, 2010 at 11:05 PM, Tim Uckun timuc...@gmail.com wrote:
No, it isn't. This is a three-way join between consolidated_urls, cu,
and tu --- the fact that cu is the same underlying table as
cu is an alias for consolidated_urls. tu is an alias for trending_urls.
There are only two
On Wed, Oct 20, 2010 at 7:24 PM, Tim Uckun timuc...@gmail.com wrote:
update cu
set screenshot_file_name = tu.screenshot_file_name,
screenshot_content_type = tu.screenshot_content_type,
screenshot_file_size = tu.screenshot_file_size,
screenshot_status = tu.screenshot_status
from
There are only two tables in the query.
Tim,
No, your query is written incorrectly. I don't understand why you come on to
this list all hostile and confrontational. Regardless, people still try to
help you and then you still ignore the advice of people that are giving you the
solutions
On Thu, Oct 21, 2010 at 9:33 AM, Brian Hirt bh...@me.com wrote:
There are only two tables in the query.
Tim,
No, your query is written incorrectly. I don't understand why you come on to
this list all hostile and confrontational. Regardless, people still try to
help you and then you
On 10/21/2010 10:27 AM, Scott Marlowe wrote:
On Thu, Oct 21, 2010 at 9:33 AM, Brian Hirt bh...@me.com wrote:
There are only two tables in the query.
Tim,
No, your query is written incorrectly. I don't understand why you come on
to this list all hostile and confrontational.
On Thu, Oct 21, 2010 at 10:37 AM, Rob Sargent robjsarg...@gmail.com wrote:
On 10/21/2010 10:27 AM, Scott Marlowe wrote:
On Thu, Oct 21, 2010 at 9:33 AM, Brian Hirt bh...@me.com wrote:
There are only two tables in the query.
Tim,
No, your query is written incorrectly. I don't understand
On Thu, Oct 21, 2010 at 1:37 PM, Rob Sargent robjsarg...@gmail.com wrote:
On 10/21/2010 10:27 AM, Scott Marlowe wrote:
On Thu, Oct 21, 2010 at 9:33 AM, Brian Hirt bh...@me.com wrote:
There are only two tables in the query.
Tim,
No, your query is written incorrectly. I don't
On 10/21/2010 10:45 AM, Scott Marlowe wrote:
On Thu, Oct 21, 2010 at 10:37 AM, Rob Sargent robjsarg...@gmail.com wrote:
On 10/21/2010 10:27 AM, Scott Marlowe wrote:
On Thu, Oct 21, 2010 at 9:33 AM, Brian Hirt bh...@me.com wrote:
There are only two tables in the query.
Tim,
No, your
On Thu, Oct 21, 2010 at 11:18 AM, Rob Sargent robjsarg...@gmail.com wrote:
On 10/21/2010 10:45 AM, Scott Marlowe wrote:
On Thu, Oct 21, 2010 at 10:37 AM, Rob Sargent robjsarg...@gmail.com wrote:
On 10/21/2010 10:27 AM, Scott Marlowe wrote:
On Thu, Oct 21, 2010 at 9:33 AM, Brian Hirt
On Fri, Oct 22, 2010 at 4:33 AM, Brian Hirt bh...@me.com wrote:
There are only two tables in the query.
Tim,
No, your query is written incorrectly. I don't understand why you come on to
this list all hostile and confrontational. Regardless, people still try to
help you and then you
True. His only real snark was in reponse to the let me google that
for you link. OTOH, he's arguing with Tom Lane about whether his SQL
is well formed. There's arguing on the internet is stupid, then
there's arguing with Tom Lane about SQL is stupid.
I wasn't arguing with Tom Lane about
On Thu, Oct 21, 2010 at 4:31 PM, Tim Uckun timuc...@gmail.com wrote:
On Fri, Oct 22, 2010 at 4:33 AM, Brian Hirt bh...@me.com wrote:
There are only two tables in the query.
Tim,
No, your query is written incorrectly. I don't understand why you come on
to this list all hostile and
I have a very simple update query.
update cu
set screenshot_file_name = tu.screenshot_file_name,
screenshot_content_type = tu.screenshot_content_type,
screenshot_file_size = tu.screenshot_file_size,
screenshot_status = tu.screenshot_status
from cu
inner join tu on tu.cu_id = cu.id
Where is the FAST button for postgres updates? What parameter do I
have to set in order to update 6000 records in under an hour?
Which version of Postgres? Have you investigated more than just two
performance tuning parameters? Does your MS Access version of the
query run any faster?
On Thu, Oct 21, 2010 at 3:37 PM, Gary Chambers gwch...@gmail.com wrote:
Where is the FAST button for postgres updates? What parameter do I
have to set in order to update 6000 records in under an hour?
Which version of Postgres?
8.4
Have you investigated more than just two
performance
Tim Uckun wrote:
BTW I have read many of those links and have adjusted some values but
honestly there are so many buttons to push and knobs to dial that it's
hard to know what will fix what.
Generally update/delete tuning goes like this:
1) Increase checkpoint_segments (64, increases
1) Increase checkpoint_segments (64, increases beyond that can be helpful
but they eventually level out)
Changed it back to 64 from 256
2) Increase shared_buffers (~25% of RAM is normal)
Changed it to one gig (25% of my RAM) obviously this involved changing
the shmmax and shmall settings in
To follow up...
I did a full vacuum analyze on both tables and re-ran the query. Same
story. I ended the query after eight minutes.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Tim Uckun timuc...@gmail.com writes:
I have a very simple update query.
update cu
set screenshot_file_name = tu.screenshot_file_name,
screenshot_content_type = tu.screenshot_content_type,
screenshot_file_size = tu.screenshot_file_size,
screenshot_status = tu.screenshot_status
On Thu, Oct 21, 2010 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Uckun timuc...@gmail.com writes:
I have a very simple update query.
update cu
set screenshot_file_name = tu.screenshot_file_name,
screenshot_content_type = tu.screenshot_content_type,
screenshot_file_size =
Tim Uckun timuc...@gmail.com writes:
Here is the actual query.
update consolidated_urls
set screenshot_file_name = tu.screenshot_file_name,
screenshot_content_type = tu.screenshot_content_type,
screenshot_file_size = tu.screenshot_file_size,
screenshot_status =
No, it isn't. This is a three-way join between consolidated_urls, cu,
and tu --- the fact that cu is the same underlying table as
cu is an alias for consolidated_urls. tu is an alias for trending_urls.
There are only two tables in the query.
consolidated_urls doesn't change that. And the
One more follow up.
Did a vacuum full on both tables and a re-index on both tables.
Changed the wal_buffers to 16MB (increased the kernel param as a
result) as per
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
I also turned off fsync but still no joy.
--
Sent via
26 matches
Mail list logo
