On Sun, Nov 18, 2012 at 1:29 AM, Tom Lane wrote:
> David Johnston writes:
>> On Nov 17, 2012, at 20:43, John R Pierce wrote:
>>> I think he meant a tiny tiny bit faster, primarily due to not having to
>>> validate the length.
>
>> Maybe... But I would presume a "varchar with no limit" does not
David Johnston writes:
> On Nov 17, 2012, at 20:43, John R Pierce wrote:
>> I think he meant a tiny tiny bit faster, primarily due to not having to
>> validate the length.
> Maybe... But I would presume a "varchar with no limit" does not validate
> length...
There is overhead from the type sy
"Greg Sabino Mullane" writes:
>> If it's a postgres bug, what is the fix? Make the identifier max size
>> longer?
> I'd also be in favor of this, in addition to upgrading from a NOTICE.
Increasing NAMEDATALEN has been discussed, and rejected, before. It
is very very far from being a free change
On 18/11/12 17:10, Phil Sorber wrote:
On Nov 17, 2012 11:06 PM, "Gavin Flower"
mailto:gavinflo...@archidevsys.co.nz>>
wrote:
>
> On 18/11/12 16:49, Greg Sabino Mullane wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>>> NOTICE: identifier
>>> "this_is_a_really_long_i
On Nov 17, 2012 11:06 PM, "Gavin Flower"
wrote:
>
> On 18/11/12 16:49, Greg Sabino Mullane wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>>> NOTICE: identifier
>>> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
>>> will be truncated to
>>> "this_is_
On 18/11/12 16:49, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NOTICE: identifier
"this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
will be truncated to
"this_is_a_really_long_identifier_for_a_prepared_statement_name_"
PREPARE
...
The ORM
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> NOTICE: identifier
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
> will be truncated to
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_"
> PREPARE
...
> The ORM could use a shorter identifier, but it
On 2012-11-06, Kevin Grittner wrote:
> hari.fu...@gmail.com
>
>> No: the result of e.g.
>>
>> SELECT TIMESTAMPTZ '2012-10-28 01:30:00' + INTERVAL '24 hours';
>>
>> depends on the client's timezone and its DST rules.
>
> Can you give an example of where adding an interval based on *hours*
> to T
On 2012-11-06, Kevin Grittner wrote:
>
> For TIMESTAMP WITHOUT TIME ZONE it couldn't be IMMUTABLE, because the
> result would be based on the time zone setting of the client
> connection; but adding a fixed interval to a UTC time to get a UTC
> time seems pretty immutable to me. That said, I'm not
On 2012-11-06, Albe Laurenz wrote:
> hari.fu...@gmail.com wrote:
>> > I think the problem is that this + operator is implemented
>> > by the function "timestamptz_pl_interval", which is STABLE
>> > but not IMMUTABLE.
>> >
>> > I am not sure why this function cannot be IMMUTABLE, it
>> > seems to m
On Nov 17, 2012, at 20:43, John R Pierce wrote:
> On 11/17/12 5:37 PM, David Johnston wrote:
>> On Nov 17, 2012, at 20:11, Jasen Betts wrote:
>>> >On 2012-11-05, Moshe Jacobson wrote:
>>But more importantly, what's the practical difference between varchar
>>with
>>no limit and
On 11/17/12 5:37 PM, David Johnston wrote:
On Nov 17, 2012, at 20:11, Jasen Betts wrote:
>On 2012-11-05, Moshe Jacobson wrote:
>>But more importantly, what's the practical difference between varchar with
>>no limit and text?
>text is immeasurably faster.
If it cannot be measured then how ca
On Nov 17, 2012, at 20:11, Jasen Betts wrote:
> On 2012-11-05, Moshe Jacobson wrote:
>
>> But more importantly, what's the practical difference between varchar with
>> no limit and text?
>
> text is immeasurably faster.
>
>>
If it cannot be measured then how can you claim this?
Everything
On 2012-11-05, Moshe Jacobson wrote:
> --14dae93404f5f865d804cdc59353
> Content-Type: text/plain; charset=ISO-8859-1
>
> Is there any practical difference between defining a column as a
> varchar(n)vs. a varchar
> vs. a text field?
>
> I've always been under the impression that if I am wanting to
On Fri, Nov 16, 2012 at 11:09 AM, Sébastien Lardière
wrote:
> On 11/15/2012 08:40 PM, Cédric Villemain wrote:
>> top post: this looks like a plproxy bug (no ?), I've added Marko in CC.
>
> Yes, it is, i think …
Thanks, fixed in git. Fix will be in 2.5 release.
--
marko
--
Sent via pgsql-gen
On Sat, Nov 17, 2012 at 11:01:41AM -0500, Mike Jarmy wrote:
> I am researching how to set up a schema for querying a set of tags
> associated with an object. There are approximately 100 distinct tags
> in my application (these will be pre-populated), and I am expecting a
> fairly low number of dis
On 11/17/2012 07:33 AM, T. E. Lawrence wrote:
Have you looked at the below?:
http://www.postgresql.org/docs/9.2/interactive/hot-standby.html#HOT-STANDBY-CONFLICT
25.5.2. Handling Query Conflicts
Yes, thank you!
I am hoping to hear more from people who have running 9.2 systems w/ between
100
> I am researching how to set up a schema for querying a set of tags
> associated with an object.
I would be interested in hearing your conclusions.
I am currently researching in a similar direction.
We have streaming replication where the slaves are used for data mining,
storing currently abou
I am researching how to set up a schema for querying a set of tags
associated with an object. There are approximately 100 distinct tags
in my application (these will be pre-populated), and I am expecting a
fairly low number of distinct sets of these tags -- in other words, a
given set of tags wil
> Have you looked at the below?:
>
> http://www.postgresql.org/docs/9.2/interactive/hot-standby.html#HOT-STANDBY-CONFLICT
>
> 25.5.2. Handling Query Conflicts
Yes, thank you!
I am hoping to hear more from people who have running 9.2 systems w/ between
100m and 1b records, w/ streaming replicat
On 11/17/2012 06:08 AM, T. E. Lawrence wrote:
> Hello,
>
> We are running 9.2 w/ streaming replication.
>
> The slave is used for heavy tsearch based data mining.
>
> Apparently depending on the business of the master the slave queries fail
> with different frequency with the following message
Hello,
We are running 9.2 w/ streaming replication.
The slave is used for heavy tsearch based data mining.
Apparently depending on the business of the master the slave queries fail with
different frequency with the following message —
ERROR: canceling statement due to conflict with recovery
D
22 matches
Mail list logo
