2008/8/29 Bill Todd <[EMAIL PROTECTED]>
> If I have a series of RAISE NOTICE 'xxx' statements in a plpgsql function
> and I call the function from pgAdmin the notice messages are concatenated on
> a single line on the Messages tab. Is there any way to get each message to
> appear on a separate lin
Bill Todd <[EMAIL PROTECTED]> writes:
> The following SELECT INTO returns incorrect values in the variables
> CATEGORY_NAME and PARENT_ID. If I copy the SELECT statement to pgAdmin,
> delete the INTO clause and run the query it returns the correct values.
You didn't show us the whole function d
Tom Lane wrote:
Maxim Boguk <[EMAIL PROTECTED]> writes:
[ ndistinct estimates way off ]
Estimating the number of distinct values in a distribution with a long
tail is just a really hard problem :-(
If I have a table where I know it has this property, is there
any way I can tell autovacuum's
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Fri, Aug 29, 2008 at 4:38 PM, Oliver Weichhold <[EMAIL PROTECTED]> wrote:
>> Consider this query:
>>
>> SELECT * FROM foo WHERE realm_id = 228 order by foo_name LIMIT 200 OFFSET
>> 15000
> try this:
> SELECT * FROM foo WHERE realm_id = 228 order b
The following SELECT INTO returns incorrect values in the variables
CATEGORY_NAME and PARENT_ID. If I copy the SELECT statement to pgAdmin,
delete the INTO clause and run the query it returns the correct values.
I am new to PostgreSQL and I must have something syntactically wrong in
the SELECT
On Fri, Aug 29, 2008 at 4:38 PM, Oliver Weichhold <[EMAIL PROTECTED]> wrote:
> Hello
>
> I have problem in my applications and don't know how to fix it.
>
> This is the table and one of the indexes:
>
> CREATE TABLE foo
> (
> id serial NOT NULL,
> foo_name character varying(100),
> realm_id i
I'm no expert at reading query plans, but I'm guessing the planner chose the
other plan because your offset + limit went beyond the row estimate.
Look's like it's then doing a disk based sort in the other plan which
probably explain why it's slow.
Someone please correct me if I'm wrong.
If I have a series of RAISE NOTICE 'xxx' statements in a plpgsql
function and I call the function from pgAdmin the notice messages are
concatenated on a single line on the Messages tab. Is there any way to
get each message to appear on a separate line?
Is there a better way than using RAISE NO
Hello
I have problem in my applications and don't know how to fix it.
This is the table and one of the indexes:
CREATE TABLE foo
(
id serial NOT NULL,
foo_name character varying(100),
realm_id integer
... and about 50 other columns
)
CREATE INDEX idx_foo_name_realm
ON foo
USING btr
Phoenix Kiula wrote:
Thanks Andrew.
On the server (the DB to be dumped) everything is "UTF8".
On my home server (where I would like to mirror the DB), this is the output:
=# \l
List of databases
Name| Owner | Encoding
---+-+---
pos
"Roberts, Jon" <[EMAIL PROTECTED]> writes:
> This is what I'm trying to understand. At what point does PostgreSQL
> determine it needs to create a new temp schema versus reusing an
> existing one? Maybe we are doing something incorrectly in our code.
They're associated with backends' slot number
-- Original message --
From: "Phoenix Kiula" <[EMAIL PROTECTED]>
> On 8/30/08, Adrian Klaver <[EMAIL PROTECTED]> wrote:
> >
> > Might also be useful to do SHOW ALL from within the database cluster you
> > have
> > on your restore machine. Will show what choices in
Hello all,
in which system tables can I find the effective run-time values of the
autovacuum configuration parameters...
naptime, thresholds, scale factors, etc
thx
joao
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.po
On 8/30/08, Adrian Klaver <[EMAIL PROTECTED]> wrote:
>
> Might also be useful to do SHOW ALL from within the database cluster you have
> on your restore machine. Will show what choices initdb made.
>
> test=# SHOW all;
>
> lc_collate | en_US.UTF-8
> lc_ctype
On Friday 29 August 2008 8:29:55 am Phoenix Kiula wrote:
> Thanks so much! I think we may be on to something:
>
>
> On the pg_dump machine:
>
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_ME
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> Thus, when piping the output (from legacy host 192.168.2.2) to
>> populate the newly initialized cluster, by way of running (on
the new
>> host 192.168.2.3)
>> pg_dumpall -h 192.168.2.2|psql
>> an error occurs in that first sectio
On Fri, Aug 29, 2008 at 11:29:55PM +0800, Phoenix Kiula wrote:
> So how can I change the locale on my local OSX machine? This could be
> it. Thanks!
Before you start restoring, put a LANG environment variable. So
something like
LANG=en_US.UTF-8 psql
or else
LANG=en_US.UTF-8; export LANG
[oth
Thanks so much! I think we may be on to something:
On the pg_dump machine:
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="
On Friday 29 August 2008 8:12:35 am Phoenix Kiula wrote:
> On 8/29/08, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> > Hrm. Well, what about the locale, as I suggested? I have no idea if
>
> How should I check for the locale?
On Linux:
[EMAIL PROTECTED]:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_
On 29/08/2008 05:45, Tom Lane wrote:
> A general comment on those pages is that the tabular lists of functions
> are intended to give one-liner descriptions of what the functions do.
> For cases where a one-liner isn't sufficient, there's a sentence or a
> paragraph following the table.
>
> I don
On Fri, Aug 29, 2008 at 11:12:35PM +0800, Phoenix Kiula wrote:
>
> How should I check for the locale?
As the user that you issue the pg_dump with on the machine you
generated it, and as the user you're trying to use to restore the
data, at the command line type
$ locale
You end up with somethi
On 8/29/08, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
>
>
> Hrm. Well, what about the locale, as I suggested? I have no idea if
How should I check for the locale?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On Fri, Aug 29, 2008 at 10:26:14PM +0800, Phoenix Kiula wrote:
> Thanks Andrew.
>
> On the server (the DB to be dumped) everything is "UTF8".
>
> On my home server (where I would like to mirror the DB), this is the output:
Hrm. Well, what about the locale, as I suggested? I have no idea if
it'
Tom Lane wrote:
Steve Clark <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Consider testing the conditions on A at the top level, instead of
redundantly checking them inside the sub-query on B.
Thanks for the response Tom, I am a SQL neophyte, so I'll try to
rework the query.
What I meant
Thanks Andrew.
On the server (the DB to be dumped) everything is "UTF8".
On my home server (where I would like to mirror the DB), this is the output:
=# \l
List of databases
Name| Owner | Encoding
---+-+---
postgres | postgres
On Fri, Aug 29, 2008 at 01:53:28PM +0800, Phoenix Kiula wrote:
> My database encoding on BOTH the sides is UTF8. The dumped DB is UTF8.
Are you sure? I know people asked up-thread for the output of \l, but
I haven't seen it. If your encoding is UTF-8, then I don't understand
how you got non-UTF
> On Fri, Aug 29, 2008 at 1:40 PM, Roberts, Jon
<[EMAIL PROTECTED]>
> wrote:
>
> >> Why have you got thousands of them? If you are running with
thousands
> >> of active backends, may I suggest a connection pooler?
> >>
> >
> > I don't know. It looks like a bug to me where a temp table is
created
On Fri, Aug 29, 2008 at 1:40 PM, Roberts, Jon <[EMAIL PROTECTED]> wrote:
>> Why have you got thousands of them? If you are running with thousands
>> of active backends, may I suggest a connection pooler?
>>
>
> I don't know. It looks like a bug to me where a temp table is created
> and dropped o
Magnus Hagander escribió:
> Alvaro Herrera wrote:
> > Russ Brown escribió:
> >> Masis, Alexander (US SSA) wrote:
> >>>"SELECT CURRVAL(
> >>> pg_get_serial_sequence('my_tbl_name','id_col_name'));"
> >> Any reason why you can't just do this?
> >>
> >> CREATE FUNCTION last_insert_id() RETURNS bigi
> -Original Message-
>
> "Roberts, Jon" <[EMAIL PROTECTED]> writes:
> > I am noticing a large number of temp schemas in my database. We use
> > temp tables but it doesn't appear that the schemas get dropped for
some
> > reason.
>
> That's intentional. There doesn't seem a lot of value i
Alvaro Herrera wrote:
> Russ Brown escribió:
>> Masis, Alexander (US SSA) wrote:
>>>"SELECT CURRVAL(
>>> pg_get_serial_sequence('my_tbl_name','id_col_name'));"
>> Any reason why you can't just do this?
>>
>> CREATE FUNCTION last_insert_id() RETURNS bigint AS $$
>> SELECT lastval();
>> $$ LANG
Sorry, I forgot to say I am using version 8.2.6.
I already removed option -n and left only -s (sincer there are no
other user schemas in the db) and I get the same error.
However when I removed the -c option it worked fine!
And also when using a formatted dump it works ok (even with -c option)
pg
32 matches
Mail list logo