On Wed, Apr 23, 2014 at 4:08 AM, Ivan Voras wrote:
> Ok, I found out what is happening, quoting from the documentation:
>
> "GIN indexes are not lossy for standard queries, but their performance
> depends logarithmically on the number of unique words. (However, GIN
> indexes store only the words (
On 04/23/2014 11:19 AM, Mel Llaguno wrote:
> Josh,
>
> Thanks for the feedback. Given the prevalence of SSDs/VMs, it would be
> useful to start collecting stats/tuning for different operating systems
> for things like fsync (and possibly bonnie++/dd). If the community is
> interested, I¹ve got a p
Josh,
Thanks for the feedback. Given the prevalence of SSDs/VMs, it would be
useful to start collecting stats/tuning for different operating systems
for things like fsync (and possibly bonnie++/dd). If the community is
interested, I¹ve got a performance lab that I¹d be willing to help run
tests on
Mel,
> I was given anecdotal information regarding HFS+ performance under OSX as
> being unsuitable for production PG deployments and that pg_test_fsync
> could be used to measure the relative speed versus other operating systems
You're welcome to identify your source of anecdotal evidence: me.
On 04/22/2014 10: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
is a tsvector, indexed wit
On Wed, Apr 23, 2014 at 8:08 AM, Ivan Voras wrote:
> >> And here is the explain analyze: http://explain.depesz.com/s/4xm
> >> It clearly shows a bitmap index scan operation is immediately followed
> >> by a recheck operation AND that the recheck operation actually does
> >> something, because it
On 22 April 2014 17:58, Jeff Janes wrote:
> 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 wit
On Tue, Apr 22, 2014 at 01:16:15AM +, Verghese, Riya 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
