ndex for that.
And that is a poor chose. I think you need a proper btree index for update
query to work properly fast. Like index on (product_id, company_id, date_range)
WHERE upper(price_generated_test.active_range) IS NULL.
> On Wed, Apr 13, 2016 at 2:54 PM, Evgeniy Shishkin
> wrote:
>
> On 13 Apr 2016, at 20:14, Adam Brusselback wrote:
>
> Sorry, brain stopped working and I forgot to include the normal info.
>
> Postgres version: 9.5.1
> Hardware: 2 core, 4gb Digital Ocean virtual server
> OS: Debian
>
> explain analyze for an example update:
> 'Update on price_generated
> On 16 Mar 2016, at 16:37, Tom Lane wrote:
>
> Andreas Joseph Krogh writes:
>> 1. Why isnt' folder_id part of the index-cond?
>
> Because a GIN index is useless for sorting.
I don't see how gin inability to return sorted data relates to index condition.
In fact i tried to reproduce the examp
> On 16 Mar 2016, at 17:52, Evgeniy Shishkin wrote:
>
>
>> On 16 Mar 2016, at 16:37, Tom Lane wrote:
>>
>> Andreas Joseph Krogh writes:
>>> 1. Why isnt' folder_id part of the index-cond?
>>
>> Because a GIN index is useless for sorting
> On 16 Mar 2016, at 18:04, Evgeniy Shishkin wrote:
>
>>
>> On 16 Mar 2016, at 17:52, Evgeniy Shishkin wrote:
>>
>>
>>> On 16 Mar 2016, at 16:37, Tom Lane wrote:
>>>
>>> Andreas Joseph Krogh writes:
>>>> 1. Why is
> What is your Postgres version?
> Do you have correct statistics on this tables?
> Please show yours execution plans with buffers i.e. explain
> (analyze,buffers) ...
>
Fast:
Sort (cost=193101.41..195369.80 rows=907357 width=129) (actual
time=3828.176..3831.261 rows=43615 loops=1)
Outp
Sorry for disrupting the thread,
i am wondering will it be possible to use BRIN indexes to better estimate
distribution?
I mean create btree index and brin index,
probe brin during planning and estimate if abort early plan with btree will be
better.
--
Sent via pgsql-performance mailing list
> On 01 May 2015, at 13:54, David Osborne wrote:
>
> Hi,
>
> We have a query which finds the latest row_id for a particular code.
>
> We've found a backwards index scan is much slower than a forward one, to the
> extent that disabling indexscan altogether actually improves the query time.
>
> On 16 Dec 2014, at 14:51, Graeme B. Bell wrote:
>
>>
>> I don't understand the logic behind using drives,
>> which are best for random io, for sequent io workloads.
>
> Because they are also best for sequential IO. I get 1.3-1.4GB/second from 4
> SSDs in RAID or >500MB/s for single disk sy
> On 11 Dec 2014, at 15:02, Andrea Suisani wrote:
>
> On 12/10/2014 11:44 AM, Maila Fatticcioni wrote:
>> 2- I would like to use the two SDD to store the wal file. Do you think
>> it is useful or how should I use them?
>
> I definitely would give it a try.
>
I don't understand the logic behi
> On 08 Aug 2014, at 16:29, Marti Raudsepp wrote:
>
> On Fri, Aug 8, 2014 at 4:05 AM, Evgeniy Shishkin wrote:
>>>>>> select * from users join notifications on
>>>>>> users.id=notifications.user_id ORDER BY users.priority desc
>>>>
> On 08 Aug 2014, at 03:43, Evgeniy Shishkin wrote:
>
>>>> select * from users join notifications on users.id=notifications.user_id
>>>> ORDER BY users.priority desc ,notifications.priority desc limit 10;
>>
>>> In my understanding, i need to ha
>>> select * from users join notifications on users.id=notifications.user_id
>>> ORDER BY users.priority desc ,notifications.priority desc limit 10;
>
>> In my understanding, i need to have two indexes
>> on users(priority desc, id)
>> and notifications(user_id, priority desc)
>> then postgresql
My question was about that you can not have fast execution of this kind of
query in postgresql.
With any runtime configuration you just swith from seq scan and hash join to
merge join, and then you have a sort node.
In my understanding, i need to have two indexes
on users(priority desc, id)
and
Hello,
suppose you have two very simple tables with fk dependency, by which we join
them
and another attribute for sorting
like this
select * from users join notifications on users.id=notifications.user_id ORDER
BY users.priority desc ,notifications.priority desc limit 10;
Very typical web qu
Hello,
we have 3 servers with postgresql 9.3.3. One is master and two slaves.
We run synchronous_replication and fsync, synchronous_commit and
full_page_writes are on.
Suddenly master hang up with hardware failure, it is a strange bug in iLo which
we investigate with HP.
Before master was reb
On 07 Mar 2014, at 13:18, acanada wrote:
> The table entity2document2 has 30GB. In consecutive runs it gets much
> better... 30ms apron.
So you just benchmarking your hard drives with random iops.
You need more ram and faster disks.
--
Sent via pgsql-performance mailing list (pgsql-performa
On 07 Mar 2014, at 12:46, acanada wrote:
>
> El Mar 7, 2014, a las 10:39 AM, Evgeniy Shishkin escribió:
>
>>
>>> Hello Mat,
>>>
>>> Setting enable_bitmapscan to off doesn't really helps. It gets worse...
>>>
>>> x=> SET e
> Hello Mat,
>
> Setting enable_bitmapscan to off doesn't really helps. It gets worse...
>
> x=> SET enable_bitmapscan=off;
> SET
> x=> explain analyze select * from (select * from entity2document2 where
> name='ranitidine' ) as a order by a.hepval;
>
On 28.05.2013, at 2:17, John Mudd wrote:
> Thanks again.
>
> Well, I have two problems with using the CLUSTER option. It's only temporary
> since any updates, depending how much free space is reserved per page,
> requires re-running the CLUSTER. And my primary concern is that it
> arbitra
On 23.01.2013, at 20:53, AJ Weber wrote:
> I have a server that is IO-bound right now (it's 4 cores, and top indicates
> the use rarely hits 25%, but the Wait spikes above 25-40% regularly). The
> server is running postgresql 9.0 and tomcat 6. As I have mentioned in a
> previous thread,
21 matches
Mail list logo
