Saffron wrote:
> Awesome, thanks! I will give that a shot
>
> On Wed, 24 May 2017 at 6:14 pm, Tom Lane wrote:
>>
>> Jeff Janes writes:
>> > On Wed, May 24, 2017 at 1:42 PM, Sam Saffron
>> > wrote:
>> >> I have this query that is not picking t
Awesome, thanks! I will give that a shot
On Wed, 24 May 2017 at 6:14 pm, Tom Lane wrote:
> Jeff Janes writes:
> > On Wed, May 24, 2017 at 1:42 PM, Sam Saffron
> wrote:
> >> I have this query that is not picking the right index unless I hard code
> >> dates:
I have this query that is not picking the right index unless I hard code dates:
SELECT "topics".* FROM "topics"
WHERE topics.last_unread_at >= '2017-05-11 20:56:24'
"Index Scan using index_topics_on_last_unread_at on topics
(cost=0.41..8.43 rows=1 width=725) (actual time=0.005..0.065 rows=5
loop
(4 rows)
I need to be able to offset and limit the union hack in a view, which
is proving very tricky.
On Wed, Feb 4, 2015 at 9:15 PM, BladeOfLight16 wrote:
> On Tue, Feb 3, 2015 at 11:28 PM, Sam Saffron wrote:
>>
>> Note: I still consider this a bug/missing feature of sorts since
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 initially:
# create table testing(id serial primary key, dat
I have this query:
select * from topics
order by case when id=1 then 0 else 1 end, bumped_at desc
limit 30
It works fine, bumps id 1 to the front of the sort fine but is
terribly inefficient and scans
OTH
"select * from topics where id = 1" is super fast
"select * from topics order by bumped_a
One interesting option would be kicking in an extra more expensive
planning cycle after the Nth run of the query, in general a lot of
these planned queries run 1000s of times, if you add some extra cost
to run 100 it may not be prohibitive cost wise.
On Tue, Nov 18, 2014 at 8:27 AM, Tom Lane wrot
he.c', I thought that the
decision of the plan to use was purely based on the value sent in to
the prepared query. However it seems that the planner completely
ignores the value in some steps. (so, for example I was thinking that
"aaa" and "ccc" would result in completely diff
I have hit a rather odd issue with prepared queries on both pg 9.3 and 9.4 beta.
I have this table (copy at http://samsaffron.com/testing.db.gz) with a
very odd performance profile:
When I run the following prepared query it is running significantly
slower than the raw counterpart:
```
select *
9.2 is the problem instance, 9.3 is clean, I am able to do many
upgrades without issues with the same script (which spawns a clean 9.3
instance and then pg_upgrades to it.)
On Wed, Mar 26, 2014 at 11:13 AM, Adrian Klaver
wrote:
> On 03/25/2014 05:03 PM, Sam Saffron wrote:
>>
>
03/25/2014 04:32 PM, Sam Saffron wrote:
>>
>> Thanks heaps Tom,
>>
>> I can confirm corrupt db upgrades fine with pg_dump. Was wondering if
>> there are any plans to add a --no-validate to pg_upgrade, since the
>> crash seems only to happen during validation.
&
Thanks heaps Tom,
I can confirm corrupt db upgrades fine with pg_dump. Was wondering if
there are any plans to add a --no-validate to pg_upgrade, since the
crash seems only to happen during validation.
Cheers
Sam
On Wed, Mar 26, 2014 at 3:19 AM, Tom Lane wrote:
> Sam Saffron writes:
>
I am getting the following failure on a customer DB upgrading 9.2 to 9.3
Selecting previously unselected package postgresql-9.2.
Unpacking postgresql-9.2 (from
.../postgresql-9.2_9.2.8-1.pgdg12.4+1_amd64.deb) ...
Processing triggers for postgresql-common ...
Setting up postgresql-client-9.2 (9.2.8
13 matches
Mail list logo
