To whom it may concern,
My question and problem is posted on below site:
http://stackoverflow.com/questions/23147724/postgresql-9-3-on-ubuntu-server-12-04-v-s-ms-sql-server-2008-r2-on-windows-7-ul
Would you please help me to solve my problem.
Thank you for your help.
Alex,
regard
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
c
On Tue, Apr 22, 2014 at 12:57 AM, Ivan Voras wrote:
> On 22 April 2014 08:40, Heikki Linnakangas
> wrote:
> > On 04/20/2014 02:15 AM, Ivan Voras wrote:
> >> More details: after thinking about it some more, it might have
> >> something to do with tsearch2 and indexes: the large data in this case
On Tue, Apr 22, 2014 at 12:12 PM, Matthew Spilich
wrote:
> Hi all - I am a little delayed in reporting back on this issue, but it
> was indeed the hugepage defrag setting that was the cause of my issue.
>
The transparent huge pages features seems so bogus for database workloads,
that it is one o
Hi all - I am a little delayed in reporting back on this issue, but it was
indeed the hugepage defrag setting that was the cause of my issue. One item
that we noticed as we were testing this issue that I wanted to report back to
the forum is that these settings
cat /sys/kernel/mm/transpare
Heikki Linnakangas writes:
> 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.
The given query
Hi,
i'm working on a strange behaviour of planner,
_PostgreSQL version :_ 8.4
_Stats & vacuum state : _just done, the table is never changed after
creation ( Create table as...)
_Here's my query :_
SELECT *cabmnt___rfovsnide*::varchar FROM zcub_258 WHERE
*cabmnt___rfovsnide* > '201301_reel
On 22 April 2014 08:40, Heikki Linnakangas wrote:
> On 04/20/2014 02:15 AM, Ivan Voras wrote:
>> More details: after thinking about it some more, it might have
>> something to do with tsearch2 and indexes: the large data in this case
>> is a tsvector, indexed with GIN, and the query plan involves
On Tue, Apr 22, 2014 at 10:28 AM, Heikki Linnakangas
wrote:
> 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 w
