Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

2015-05-21 Thread Vitalii Tymchyshyn
It may be even easier. AFAIR, it's possible just to tell OS expected allocation without doing it. This way nothing changes for general code, it's only needed to specify expected file size on creation. Please see FILE_ALLOCATION_INFO: https://msdn.microsoft.com/en-us/library/windows/desktop/aa36421

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

2015-05-21 Thread Andres Freund
On 2015-05-21 11:54:40 -0700, Josh Berkus wrote: > This has been talked about as a feature, but would require major work on > PostgreSQL to make it possible. You'd be looking at several months of > effort by a really good hacker, and then a whole bunch of performance > testing. If you have the bu

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

2015-05-21 Thread Josh Berkus
On 04/23/2015 12:47 PM, Jan Gunnar Dyrset wrote: > I think that preallocating lumps of a given, configurable size, say 4 > MB, for the tables would remove this problem. The max number of > fragments on a 1 GB file would then be 250, which is no problem. Is > this possible to configure in PostgreSQ

Re: [PERFORM] Fastest way / best practice to calculate "next birthdays"

2015-05-21 Thread David G. Johnston
On Thursday, May 21, 2015, Bosco Rama wrote: > On 05/20/15 20:22, David G. Johnston wrote: > > On Monday, May 18, 2015, er.tejaspate...@gmail.com < > > er.tejaspate...@gmail.com > wrote: > > > >> If I have to find upcoming birthdays in current week and the current > week > >> fall into different

Re: [PERFORM] Fastest way / best practice to calculate "next birthdays"

2015-05-21 Thread Bosco Rama
On 05/20/15 20:22, David G. Johnston wrote: > On Monday, May 18, 2015, er.tejaspate...@gmail.com < > er.tejaspate...@gmail.com> wrote: > >> If I have to find upcoming birthdays in current week and the current week >> fall into different months - how would you handle that? >> > > Extract(week from

Re: [PERFORM] union all and filter / index scan -> seq scan

2015-05-21 Thread Tom Lane
Florian Lohoff writes: > It seems the planner is not able to rewrite a union all I do not see any problems with pushing indexable conditions down through a UNION ALL when I try it. I speculate that either you are using a very old 9.1.x minor release, or the actual view is more complex than you'v

Re: [PERFORM] union all and filter / index scan -> seq scan

2015-05-21 Thread Vitalii Tymchyshyn
It looks pretty much like partitioning. You should check partitioning recipes. Чт, 21 трав. 2015 06:41 Florian Lohoff пише: > Hi, > i stumbled over something i cant seem to find a workaround. I create a > view like > > create view v_test as > select a,b > frombig_table >

[PERFORM] union all and filter / index scan -> seq scan

2015-05-21 Thread Florian Lohoff
Hi, i stumbled over something i cant seem to find a workaround. I create a view like create view v_test as select a,b frombig_table union all select a,b fromsmall_table; When i now use the view like select * from v_test where a = 42; I