Hi,
Is this bug in Postgres ?
If yes, is it fixed in latest release ?
Second query should return 2 rows instead of 1 ?
create table t(i int);
insert into t values(1);
insert into t values(2);
insert into t values(3);
pgdb=# select i from t order by i limit 9223372036854775806 offset 1;
select i f
Tom Lane escribió:
> Sergey Konoplev writes:
> > On Thu, Oct 11, 2012 at 12:19 PM, Sahagian, David
> > wrote:
> >> Are there any "extra" costs to logging all this cool stuff ?
> >>
> >> log_line_prefix = '%m %a %u %p %c %m %v %x'
>
> > The formatting cost only but it is so insignificant that do
>
> We have our production environment database server in Postgres 8.3
> version. we have planned to upgrade to lastest version 9.1. Dump from 8.3
> and restore in Postgres 9.1 takes more than 5 hours. Any other quick
> method to upgrade from 8.3 to 9.1. We need to reduce our downtime below 1
> h
On 10/11/12 7:15 PM, Vishalakshi Navaneethakrishnan wrote:
We have our production environment database server in Postgres 8.3
version. we have planned to upgrade to lastest version 9.1. Dump from
8.3 and restore in Postgres 9.1 takes more than 5 hours. Any other
quick method to upgrade from 8.
On 12/10/12 15:15, Vishalakshi Navaneethakrishnan wrote:
Hi Friends,
We have our production environment database server in Postgres 8.3
version. we have planned to upgrade to lastest version 9.1. Dump from
8.3 and restore in Postgres 9.1 takes more than 5 hours. Any other
quick method to upg
Thalis Kalfigkopoulos writes:
> I see in the docs the following:
> SELECT current_date + s.a AS dates FROM generate_series(0,14,7) AS s(a);
> Trying it as:
> SELECT current_date + a AS dates FROM generate_series(0,14,7) AS a;
> yields exactly the same result.
> Does the finer granularity/expres
Hi Friends,
We have our production environment database server in Postgres 8.3 version.
we have planned to upgrade to lastest version 9.1. Dump from 8.3 and
restore in Postgres 9.1 takes more than 5 hours. Any other quick method to
upgrade from 8.3 to 9.1. We need to reduce our downtime below 1
Hi all.
I see in the docs the following:
SELECT current_date + s.a AS dates FROM generate_series(0,14,7) AS s(a);
Trying it as:
SELECT current_date + a AS dates FROM generate_series(0,14,7) AS a;
yields exactly the same result.
Does the finer granularity/expressiveness offer some extra
function
Condor writes:
> explain analyze SELECT * FROM table WHERE phone LIKE '12%' AND
> firstname = 'OLEG' AND middlename || lastname LIKE '%KUZNICOV%IGORU%';
> QUERY PLAN
> --
>
> I think the argument was that it's almost certainly a mistake, so we're
> more helpful by throwing an error than by silently executing a query
> that probably won't do what the user was expecting. In this particular
> example, it seems quite likely that the programmer meant "foo" (ie a
> quote
Sergey Konoplev writes:
> On Thu, Oct 11, 2012 at 12:19 PM, Sahagian, David
> wrote:
>> Are there any "extra" costs to logging all this cool stuff ?
>>
>> log_line_prefix = '%m %a %u %p %c %m %v %x'
> The formatting cost only but it is so insignificant that does not
> worth bothering with it.
On Thu, Oct 11, 2012 at 2:23 AM, Condor wrote:
> explain analyze SELECT * FROM table WHERE phone LIKE '12%' AND firstname =
> 'OLEG' AND middlename || lastname LIKE '%KUZNICOV%IGORU%';
> QUERY
> PLAN
> ---
On 10/11/12 2:57 PM, Sergey Konoplev wrote:
On Thu, Oct 11, 2012 at 12:19 PM, Sahagian, David
wrote:
>Are there any "extra" costs to logging all this cool stuff ?
>
> log_line_prefix = '%m %a %u %p %c %m %v %x'
The formatting cost only but it is so insignificant that does not
worth bothe
Ok. Thanks for your help.
On Oct 11, 2012, at 3:31 PM, Tom Lane wrote:
> "Evan D. Hoffman" writes:
>> Because we have both 9.0 and 9.1 running, and a query that succeeds
>> under 9.1 was failing under 9.0. Can I assume the answer then is
>> "no"?
>
> There are any number of reasons a query m
On Thu, Oct 11, 2012 at 12:19 PM, Sahagian, David
wrote:
> Are there any "extra" costs to logging all this cool stuff ?
>
> log_line_prefix = '%m %a %u %p %c %m %v %x'
The formatting cost only but it is so insignificant that does not
worth bothering with it.
--
Sergey Konoplev
a database
On Thu, Oct 11, 2012 at 2:07 PM, A.M. wrote:
> On Oct 11, 2012, at 4:48 PM, Ken Tanzer wrote:
> select * from generate_series(1,10) order by coalesce('foo');
Another workaround is
select bar.* from generate_series(1,3) as bar, (values ('foo')) as foo
order by foo;
or even simpler
select * from
On 10/11/12 2:07 AM, Vineet Deodhar wrote:
To give an example, I have tables for storing master records (year
master, security master, etc.) for which pkid TINYINT is just sufficient.
These pkid's are used as fk constraints in tables for storing business
transactions.
The no. of rows in busines
On Oct 11, 2012, at 4:48 PM, Ken Tanzer wrote:
> Hi. I recently ran a query that generate the same error as this:
>
> SELECT * FROM generate_series(1,10) ORDER BY 'foo';
> ERROR: non-integer constant in ORDER BY
> LINE 1: SELECT * FROM generate_series(1,10) ORDER BY 'foo';
>
> The query was g
Ken Tanzer writes:
> Hi. I recently ran a query that generate the same error as this:
> SELECT * FROM generate_series(1,10) ORDER BY 'foo';
> ERROR: non-integer constant in ORDER BY
> I am curious though about why this "limitation" exists. I get that integer
> constants are reserved for sortin
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Ken Tanzer
Sent: Thursday, October 11, 2012 4:49 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] non-integer constant in ORDER BY: why exactly, and
documentation?
Hi. I recently ran a query
Hi. I recently ran a query that generate the same error as this:
SELECT * FROM generate_series(1,10) ORDER BY 'foo';
ERROR: non-integer constant in ORDER BY
LINE 1: SELECT * FROM generate_series(1,10) ORDER BY 'foo';
The query was generated by an app (and the result somewhat inadvertent), so
it
"Evan D. Hoffman" writes:
> Because we have both 9.0 and 9.1 running, and a query that succeeds
> under 9.1 was failing under 9.0. Can I assume the answer then is
> "no"?
There are any number of reasons a query might work in version N and not
in N-1. If you've got requirements like that, you sh
In 9.1.x
Are there any "extra" costs to logging all this cool stuff ?
log_line_prefix = '%m %a %u %p %c %m %v %x'
Are any of these expensive ?
Or is the only cost the number of bytes that the textual representation of
their values take in the written log file ?
Thanks,
-dvs-
Evan D. Hoffman wrote on 11.10.2012 20:54:
Is there any way to disable the guessing of missing columns in a
group-by (the feature added in 9.1)?
Because we have both 9.0 and 9.1 running, and a query that succeeds
under 9.1 was failing under 9.0. Can I assume the answer then is
"no"?
If you
Because we have both 9.0 and 9.1 running, and a query that succeeds
under 9.1 was failing under 9.0. Can I assume the answer then is
"no"?
On Thu, Oct 11, 2012 at 2:38 PM, Tom Lane wrote:
> "Evan D. Hoffman" writes:
>> Is there any way to disable the guessing of missing columns in a
>> group-by
"Evan D. Hoffman" writes:
> Is there any way to disable the guessing of missing columns in a
> group-by (the feature added in 9.1)?
Why would you want to do that? There's no "guessing" involved: the
behavior is always correct, and it is required by the SQL standard.
rega
>I believe the general consensus around here is to not do that, if you can
avoid it. File systems are much better equipped to handle files of that
magnitude, especially when it comes to retrieving them, scanning >through
their contents, or really, any access pattern aside from simple storage.
>
Is there any way to disable the guessing of missing columns in a
group-by (the feature added in 9.1)? I haven't found any option but I
might not be searching for the right thing.
http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.1#SQL_and_PL.2FPgSQL_features
--
Sent via pgsql-genera
On Thu, Oct 11, 2012 at 9:38 AM, Gavin Flower wrote:
> On 12/10/12 04:39, Merlin Moncure wrote:
>
>> On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar
>> wrote:
>>
>>> Thanks all for your replies.
>>> This is my first experience with postgres mailing list.
>>> Hats Off to the active community of p
On 12/10/12 04:39, Merlin Moncure wrote:
On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar
wrote:
Thanks all for your replies.
This is my first experience with postgres mailing list.
Hats Off to the active community of pgsql.
This has definitely raised my confidence level with postgres.
thanks.
On Thu, Oct 11, 2012 at 8:56 AM, Scott Mead wrote:
> Hey Ian,
>
>
> On Thu, Oct 11, 2012 at 10:52 AM, Ian Harding wrote:
>>
>> I know this is the wrong place, but I tried creating an account on
>> their site to contact them and it does not work.
>>
>
> I'll take a look at that right away, sorry i
Hey Ian,
On Thu, Oct 11, 2012 at 10:52 AM, Ian Harding wrote:
> I know this is the wrong place, but I tried creating an account on
> their site to contact them and it does not work.
>
>
I'll take a look at that right away, sorry it happened!
> The 9.0.10 package throws an error when I try to
On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar
wrote:
> Thanks all for your replies.
> This is my first experience with postgres mailing list.
> Hats Off to the active community of pgsql.
> This has definitely raised my confidence level with postgres.
thanks. we like emails that start off 'movi
I know this is the wrong place, but I tried creating an account on
their site to contact them and it does not work.
The 9.0.10 package throws an error when I try to install it that it
has an unsatisfied dependency on libpython. Since it brings its own
libraries, I'm not sure why that would be, bu
Thanks all for the help and insights. I will continue to read up on
the details of partitioning and pgpool.
best regards,
Lars
On Thu, Oct 11, 2012 at 2:47 AM, Gavin Flower
wrote:
> On 11/10/12 12:41, Tom Lane wrote:
>>
>> Gavin Flower writes:
>>>
>>> On 11/10/12 01:03, Lars Helge Øverland w
On 10/11/2012 05:07 PM, Vineet Deodhar wrote:
On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer mailto:ring...@ringerc.id.au>> wrote:
The difference between SMALLINT and BOOLEAN (or TINYINT if Pg
supported it) is 1 byte per column. If you had 30 smallint columns
and quite a few million r
Thanks all for your replies.
This is my first experience with postgres mailing list.
Hats Off to the active community of pgsql.
This has definitely raised my confidence level with postgres.
--- Vineet
On Wed, Oct 10, 2012 at 10:56 PM, Craig Ringer wrote:
> On 10/11/2012 01:35 PM, tigran2-postg...@riatest.com wrote:
>
>> Using files stored outside the database creates all sorts of problems.
>> For starters you lose ACID guaranties. I would prefer to keep them in
>> database. We did a lot of expe
On Thu, Oct 11, 2012 at 3:04 PM, Craig Ringer wrote:
>
> AFAIK in most situations alignment requirements will mean you won't gain
> any space in those situations anyway.
>
> I would be truly amazed if you saw more than something like a 1%
> difference in size due to this; it'll be *massively* out
On 10/11/2012 05:11 PM, Vineet Deodhar wrote:
On Thu, Oct 11, 2012 at 12:56 PM, Scott Marlowe mailto:scott.marl...@gmail.com>> wrote:
Can't you just add this to your create table:
CREATE TABLE tablename (
colname SERIAL
, check (colname>0 and colname < 32768));
);
W
On Thu, Oct 11, 2012 at 5:11 PM, Vineet Deodhar wrote:
> On Thu, Oct 11, 2012 at 12:56 PM, Scott Marlowe
> wrote:
>
>>
>> Can't you just add this to your create table:
>>
>>
>> CREATE TABLE tablename (
>>colname SERIAL
>> , check (colname>0 and colname < 32768));
>> );
>>
>>
>>
> With this co
Hello,
I have a problem with query and index scan based on pg_trgm module.
Here is few examples:
First example is with equal:
explain analyze SELECT * FROM table WHERE firstname = 'OLEG' AND
middlename || lastname LIKE '%KUZNICOV%IGORU%';
On Thu, Oct 11, 2012 at 12:56 PM, Scott Marlowe wrote:
>
> Can't you just add this to your create table:
>
>
> CREATE TABLE tablename (
>colname SERIAL
> , check (colname>0 and colname < 32768));
> );
>
>
>
With this constraint, whether the storage space requirement would reduce?
OR
Is it just
On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer wrote:
> The difference between SMALLINT and BOOLEAN (or TINYINT if Pg supported
> it) is 1 byte per column. If you had 30 smallint columns and quite a few
> million rows it might start making a difference, but it's *really* not
> worth obsessing abou
On 10/11/2012 03:04 PM, Vineet Deodhar wrote:
user_id smallint NOT NULL DEFAULT nextval('user_id_seq')
I'm kind of puzzled about why you'd want to use a serial on a field that
can contain at most 65,536 entries anyway. If you're only going to have
a max of 65,536 entries then the spa
On 10/11/2012 02:07 PM, Vineet Deodhar wrote:
On Thu, Oct 11, 2012 at 5:26 AM, Ondrej Ivanič mailto:ondrej.iva...@gmail.com>> wrote:
Hi,
On 10 October 2012 19:47, Vineet Deodhar mailto:vineet.deod...@gmail.com>> wrote:
> 3) Can I simulate MySQL's TINYINT data-type (using maybe the
On Thu, Oct 11, 2012 at 1:04 AM, Vineet Deodhar
wrote:
> I wish to know regarding auto-increment field.
> I learn that the required table definition would be something like --
>
> CREATE TABLE tablename (
> colname SERIAL
> );
>
> For more granular control over the size of field, I need to do
I wish to know regarding auto-increment field.
I learn that the required table definition would be something like --
CREATE TABLE tablename (
colname SERIAL
);
For more granular control over the size of field, I need to do the following---
CREATE SEQUENCE user_id_seq;
CREATE TABLE user (
48 matches
Mail list logo
