Fujii Masao writes:
> On Fri, Aug 6, 2010 at 7:50 AM, Simon Riggs wrote:
>> The procedure used does differ from that documented. However, IMHO the
>> procedure *documented* is *not* safe and could lead to corrupt indexes
>> in the way described, since the last recovered point might be mid-way
>>
On Fri, Aug 6, 2010 at 7:50 AM, Simon Riggs wrote:
> The procedure used does differ from that documented. However, IMHO the
> procedure *documented* is *not* safe and could lead to corrupt indexes
> in the way described, since the last recovered point might be mid-way
> between two halves of an in
On Sun, Aug 1, 2010 at 10:16 PM, runner.mei wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5588
> Logged by: runner.mei
> Email address: runner@gmail.com
> PostgreSQL version: 8.4.4
> Operating system: windows
> Description: I use a lot of t
On Wed, Aug 11, 2010 at 4:47 PM, Brian Ceccarelli wrote:
> Please show me an example where an inline query gets a performance boost.
Sure.
rhaas=# create table example as select a from
generate_series(1,10) a; SELECT 10
rhaas=# alter table example add primary key (a);
NOTICE: ALTER
Excerpts from Brian Ceccarelli's message of mié ago 11 16:47:50 -0400 2010:
> Please show me an example where an inline query gets a performance boost.
The reason it's a performance boost is that the query gets to be planned
as a single query, instead of there being a black-box that needs to be
p
Robert Haas writes:
> In theory, the optimization Brian wants is possible here, right? I
> mean, you could replace the functional call with a Param, and pull the
> Param out and make it an InitPlan. Seems like that would generally be
> a win, if you figure to loop more than once and the executio
1. Basically, I was assuming that "STABLE" was more than just a optimizer
"hint".
2. Is it not better to evaluate a STABLE function once, and pass the returned
constant to a function, than pass the function itself and inline it? Is not
passing a constant more efficient than even an inline q
The following bug has been logged online:
Bug reference: 5613
Logged by: Scott
Email address: wheels7...@hotmail.com
PostgreSQL version: 8.4
Operating system: vista
Description:cannot delete
Details:
I have recently tried to install PostgreSQL to use with poker trac
Brian Ceccarelli writes:
> OK. The documentation says "allows the optimizer to optimize . . . ."
> But then the example guarantees the one-time-only for a index scan condition.
>
No, the documentation states that *if* an index scan is used, functions
involved in the indexscan's qual con
On Wed, Aug 11, 2010 at 11:50 AM, Brian Ceccarelli
wrote:
> OK. The documentation says "allows the optimizer to optimize . . . ."
> But then the example guarantees the one-time-only for a index scan condition.
>
> From the documentation: 8.4.4 Chapter 32 and 8.2.17 Chapter 33.
>
> .A ST
LinkedIn
I'd like to add you to my professional network on LinkedIn.
- Lucian Capdefier
Lucian Capdefier
Business Analytics and Optimization Service Line Leader at IBM Global Business
Services
Romania
Confirm that you know Lucian Capdefier
https://www.linkedin.com/e/-fsh06j-g
On 09/08/10 21:29, Heikki Linnakangas wrote:
On 09/08/10 21:26, Tom Lane wrote:
Heikki Linnakangas writes:
The behavior of empty arrays with dimensions is weird in general.
Agreed, but we shouldn't be introducing random restrictions in the name
of security.
Patch looks good to me, except tha
[moving discussion to -hackers]
Michael Meskes wrote:
> "Kevin Grittner" schrieb:
>>"Marcelo Mas" wrote:
>>
>>> Valgrind reports memmory leak when getting decimal data.
>>
>>I wonder how much overlap there is between this and the patch for
>>fixing ECPG memory leaks offered by Zoltán Böszörmé
Excerpts from Ramachandran S's message of mié ago 11 05:36:31 -0400 2010:
> I have observed that if a table exceeds size (default installation) 1 GB.
> The table when it exceeds 1 GB a file is created say 1811(table) with 1811.1
> and further records added are insertted into this file. My Quest
OK. The documentation says "allows the optimizer to optimize . . . ."But
then the example guarantees the one-time-only for a index scan condition.
From the documentation:8.4.4 Chapter 32 and 8.2.17 Chapter 33.
.A STABLE function cannot modify the database and is guaranteed to ret
On Wed, Aug 11, 2010 at 11:01 AM, Brian Ceccarelli
wrote:
> My complaint remains. That inlined function f_return_ver_id_4() is a
> STABLE function, inlined or not. Postgres now calls it multiple times during
> the transaction, even though the arguments to f_return_ver_id_4() have not
> ch
Brian Ceccarelli writes:
> STABLE no longer means STABLE. This behavior is killing my performance.
> I am getting 500% to 3% increase in latency.
You seem to be under the illusion that "stable" is a control knob for a
function result cache. It is not, and never has been. Postgres do
Dear Tom,
Thanks for getting back to me so soon.
I see that SQL functions seem to inline their calling arguments.
My complaint remains. That inlined function f_return_ver_id_4() is a
STABLE function, inlined or not. Postgres now calls it multiple times during
the transaction,
"Ramachandran S" wrote:
> I have observed that if a table exceeds size (default
> installation) 1 GB. The table when it exceeds 1 GB a file is
> created say 1811(table) with 1811.1 and further records added are
> insertted into this file. My Question if I remove the file 1811.1
> say still dat
The following bug has been logged online:
Bug reference: 5612
Logged by: Ramachandran S
Email address: nic.sr...@gmail.com
PostgreSQL version: 8.4
Operating system: Ubuntu
Description:Database Integrity
Details:
I have observed that if a table exceeds size (default
On Fri, Aug 6, 2010 at 12:31 AM, Jon Erdman (aka StuckMojo)
wrote:
> Description: Setting NOT NULL on inherited column turns to real
> column in dump
>
> I think the fix here is relatively simple: make NOT NULL on an inherited
> column dump as an ALTER TABLE.
>
> If you set NOT NULL on an i
21 matches
Mail list logo
