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 (
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
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 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 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 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
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 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
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 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 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
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 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 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
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
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
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 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
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 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
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
>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.
>
"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
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 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
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" 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
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
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
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
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
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 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 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
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 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
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
> ---
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.
>
> 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
Condor writes:
> explain analyze SELECT * FROM table WHERE phone LIKE '12%' AND
> firstname = 'OLEG' AND middlename || lastname LIKE '%KUZNICOV%IGORU%';
> QUERY PLAN
> --
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
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
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
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
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.
>
> 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
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
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
48 matches
Mail list logo
