Re: [GENERAL] VACUUM FULL pg_largeobject without (much) downtime?

2015-02-04 Thread Adam Hooper
On Tue, Feb 3, 2015 at 3:12 PM, Bill Moran wrote: > On Tue, 3 Feb 2015 14:48:17 -0500 > Adam Hooper wrote: > >> It's doable for us to VACUUM FULL and add a notice to our website >> saying, "you can't upload files for the next two hours." Maybe that's >> a better idea? > > It's really going to dep

Re: [GENERAL] How do I bump a row to the front of sort efficiently

2015-02-04 Thread Paul Jungwirth
>> I imagine your original would be at risk of LIMITing out the very row you >> seek to get at the "top", since you don't have an ORDER BY to tell it which >> ones to keep during the outer LIMIT. Here is an old thread about combining ORDER BY with UNION: http://www.postgresql.org/message-id/16814

Searching postgres soruces (was: Re: [GENERAL] array in a store procedure in C)

2015-02-04 Thread Merlin Moncure
On Tue, Feb 3, 2015 at 4:20 PM, Jim Nasby wrote: > On 2/3/15 7:03 AM, holger.friedrich-fa-triva...@it.nrw.de wrote: >> >> On Tuesday, February 03, 2015 3:58 AM, Jim Nasby wrote: >>> >>> Note that the recursive grep starts at the current directory, so make >>> sure you're actually in the pgsql sour

Re: [GENERAL] How do I bump a row to the front of sort efficiently

2015-02-04 Thread Sam Saffron
The union hack may be able to work, but what I want is slightly more complex I want this to work efficiently, even without the case it chokes: explain select * from testing order by id in (100,2,-1) desc, id limit 30; QUERY PLAN

Re: [GENERAL] How do I bump a row to the front of sort efficiently

2015-02-04 Thread BladeOfLight16
On Tue, Feb 3, 2015 at 11:28 PM, Sam Saffron wrote: > Note: I still consider this a bug/missing feature of sorts since the > planner could do better here, and there is no real clean way of > structuring a query to perform efficiently here, which is why I > erroneously cross posted this to hacker