More and more lenses

This is actually getting to be fun. The more I look, the more bargains I am discovering. Apparently the 55-250 and the 70-300mm f/4-5.6 USM IS are pretty highly thought of lenses that don't carry a large price tag. The 55-250 is $255 brand new. The 70-300 comes in at $550. So that gives me some more thinking to do and options to consider. My big concern would be if these would work well for shooting my son's soccer games. Not sure how the AF works on these regarding sports. I'll have to look into it some more.

Comments

Post a Comment

Popular posts from this blog

Database, schema, and table sizes in Greenplum

Starting in the 4.x release, you get size info from the gp_toolkit schema. To get the size of all databases and their size in bytes: select sodddatname, sodddatasize from gp_toolkit.gp_size_database; To see the database size in GB, TB, and/or MB. TB: select sodddatname, (sodddatsize/1073741824)/1024 AS sizeinTB from gp_toolkit.gp_size_of_database; GB: select sodddatname, (sodddatsize/1073741824) AS sizeinGB from gp_toolkit.gp_size_of_database; MB: select sodddatname, (sodddatsize/1048576) AS sizeinMB from gp_toolkit.gp_size_of_database; For schema sizes , connect to your database and run: TB: select sosdnsp, (sosdschematablesize/1073741824)/1024 AS schemasizeinTB from gp_toolkit.gp_size_of_schema_disk; GB: select sosdnsp, (sosdschematablesize/1073741824) AS schemasizeinGB from gp_toolkit.gp_size_of_schema_disk; MB: select sosdnsp, (sosdschematablesize/1048576) AS schemasizeinMB from gp_toolkit.gp_size_of_schema_disk; If you want a specific schema only, add
Read more

Greenplum update with multiple tables

Recently ran into an issue using Greenplum to update a column. I had column1 in tableA that needed to be set to the value of column1 in tableB. Finally came across the correct syntax here . This is what I was looking for: UPDATE tableA  SET col1 = tableB.col1  FROM tableB  WHERE tableA.col2=tableB.col2;
Read more

Show running queries on Postgresql/Greenplum

I've got some queries that run for a long time. Sometimes longer than others. I wanted to see how long active queries have been running. Here's a view to consistently do that: CREATE VIEW public.view_activequeries AS ( SELECT age(query_start, backend_start) AS queryage,* FROM pg_stat_activity WHERE current_query NOT LIKE '%IDLE%' ORDER BY queryage DESC); Then you just run: select * from public.view_activequeries; You get a list of all active queries in descending order of how long they have been running, i.e. longest running queries listed first.
Read more