On 04/20/2014 02:15 AM, Ivan Voras wrote:
Hello,
If a table contains simple fields as well as large (hundreds of KiB)
text fields, will accessing only the simple fields cause the entire
record data, including the large fields, to be read and unpacked?
(e.g. SELECT int_field FROM table_with_large
On 04/20/2014 07:46 AM, Oleg Bartunov wrote:
btw, 9.4 should be wiser in case of rare+common terms, thanks to GIN
fast scan feature.
Indeed, although we didn't actually do anything to the planner to make
it understand when fast scan helps. Doing something about cost
estimation is still on the
On Mon, Apr 21, 2014 at 6:19 PM, Tory M Blue wrote:
> I am going to add a new column to a table for modify_date that needs to be
> updated every time the table is updated. Is it better to just update
> application code to set the modify_date to current_time, or create a
> Before-Update trigger on
Tory M Blue wrote
> Hi
> I am going to add a new column to a table for modify_date that needs to be
> updated every time the table is updated. Is it better to just update
> application code to set the modify_date to current_time, or create a
> Before-Update trigger on the table that will update the
Hi
I am going to add a new column to a table for modify_date that needs to be
updated every time the table is updated. Is it better to just update
application code to set the modify_date to current_time, or create a
Before-Update trigger on the table that will update the modify_date column
to curre
On Fri, Apr 18, 2014 at 3:07 AM, Franck Routier
wrote:
> I have found the problem, using this query (found here
> http://stackoverflow.com/questions/3312929/postgresql-idle-in-transaction-diagnosis-and-reading-pg-locks)
>
> select pg_class.relname, pg_locks.transactionid, pg_locks.mode,
>p
