Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> I've been reading about these problems (but never experienced myself). I've
> always wondered if it would be possible to write a script to scan through a
> schema dump searching for dependancies. You can then use tsort to dump out
> the order tha
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> statistic ( n_distinct in particular) records for one of my columns,
>> greatly under calculated it saying:
>> 49726, but in reality 33409816.
>> is it any way how I can improve that?
> You might see if raising the statistics target with ALTER TABLE ALT
Here are some upcoming events:
This week, there is the O'Reilly Open Source Convention in Portland,
Oregon. Our BOF is Wednesday night at 8pm, and we have a full day of
PostgreSQL classes on Thursday.
I will be speaking at LinuxTag in Germany this Saturday at 1:30pm.
I have another training cla
I've been reading about these problems (but never experienced myself). I've
always wondered if it would be possible to write a script to scan through a
schema dump searching for dependancies. You can then use tsort to dump out
the order that things should be restored in.
Has anyone attempted this
Hi,
are there
any
Windows based
native data providers
for
PostGreSql
that
can be used from .Net applications
other
than Mono
regards-adivi
Andrew Gould wrote:
--- Timothy Brier <[EMAIL PROTECTED]> wrote:
Hi,
I've run in to this problem with a database we are
working. When I
restore a database schema, I need to restore the
schema 5 times to
ensure that the schema is complete. Also some of
the sequences are not
restored in a usab
--- Timothy Brier <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've run in to this problem with a database we are
> working. When I
> restore a database schema, I need to restore the
> schema 5 times to
> ensure that the schema is complete. Also some of
> the sequences are not
> restored in a usable
POSTGRESQL ADVOCACY FUND
Robert Treat has been selected by the Core Team as Treasurer for our new
PostgreSQL Advocacy Fund. Robert will soon be setting up an account in
the U.S. for receiving donations for the promotion of PostgreSQL. This
fund will be used primarily to print promotional materi
On Tue, 8 Jul 2003, Maksim Likharev wrote:
> Hi,
> I just found very interesting situation,
> statistic ( n_distinct in particular) records for one of my columns,
> greatly under calculated it saying:
>
> 49726, but in reality 33409816.
>
> So planer never choose index but rather using table scan
I have a query where I want to select the usertable records that have a matching entry in
an event table. There are two ways to do this.
1) SELECT COUNT(DISTINCT u.uid) FROM usertable u, eventlog e WHERE u.uid = e.uid AND
e.type = XX;
2) SELECT COUNT(u.uid) FROM usertable u WHERE EXISTS(SELECT
Hi,
I've run in to this problem with a database we are working. When I
restore a database schema, I need to restore the schema 5 times to
ensure that the schema is complete. Also some of the sequences are not
restored in a usable form. E.g. If my next sequence should be 1000, my
sequence is
The link at the end of 1.6 in the faq does not work.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mai
Hi,
I just found very interesting situation,
statistic ( n_distinct in particular) records for one of my columns,
greatly under calculated it saying:
49726, but in reality 33409816.
So planer never choose index but rather using table scan, and query
never returns,
is it any way how I can improve
I would referrer dump that gar.xxg, and put PG on Linux,
but this is not up to me.
Thanks for the help.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 3:58 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG
On Tue, 8 Jul 2003, Clay Luther wrote:
> My initial impression is that AFTER triggers written in C cannot abort
> the wrapping transaction if an error occurs. Is this correct?
After triggers can still raise an exception condition to abort the
transaction with elog. They can't quietly change or
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> On failure, strxfrm() returns (size_t)-1.
Not according to the Single Unix Specification, Linux, or HP-UX;
I don't have any others to check. But anyway, that is not causing
your problem, since palloc(0) would complain not dump core.
> I am on
Interesting. The compiler doesn't do x86_64 by default --- you have to
enable it in the compile.
Any idea how to handle this in our builds? It doesn't seem like a
property of the OS as much as a property of the compiler --- we
already do 64-bit on some platforms without flags.
What is the full
The s_lock.h change will be in 7.4.
---
Tom Lane wrote:
> "Martin D. Weinberg" <[EMAIL PROTECTED]> writes:
> > I didn't change the source tree at all. I used:
>
> > env CFLAGS='-O3 -m64' LD='/usr/bin/ld -melf_x86_64' ./con
My initial impression is that AFTER triggers written in C cannot abort the wrapping
transaction if an error occurs. Is this correct?
---
Clay
Cisco Systems, Inc.
[EMAIL PROTECTED]
(972) 813-5004
I've stopped 15,797 spam messages. You can too!
One month FREE spam protection at http://www.cloudm
On Tue, 8 Jul 2003, Andrew Sullivan wrote:
> On Mon, Jul 07, 2003 at 08:39:13PM -0500, Daniel Armbrust wrote:
> > Do you realize your entire website is hosed? NONE of the download sites
> > will resolve, and NONE of the mirror sites work (or will resolve).
>
> > What is up?
>
> Maybe you have a b
On 2003.07.07 11:56 Mat wrote:
> I believe that its more efficient to group INSERT's together and COMMIT
> them in groups.
> However, I am automatically entering a lot of data and some of its is
> not unique. How can I reap the benefits of using BEGIN and COMMIT
> without the whole block of transac
On Tuesday 08 Jul 2003 7:48 pm, Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > Can I ask why, since the plan is constructed at query-time the parameters
> > aren't substitued *before* planning?
>
> Because then the plan couldn't be re-used. A SQL function may be
> executed many t
>> !if error happend, xfrmlen will be (size_t)-1
>No it won't; see the man page for strxfrm.
RETURN VALUES
Upon successful completion, strxfrm() returns the length of
the transformed string (not including the terminating null
byte). If the value returned is n or more
Richard Huxton <[EMAIL PROTECTED]> writes:
> Can I ask why, since the plan is constructed at query-time the parameters
> aren't substitued *before* planning?
Because then the plan couldn't be re-used. A SQL function may be
executed many times in a query, so the plan has to be reusable.
(Or, if y
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> ! I would say very interesting aproach,
> ! why not just
> xfrmsize = strxfrm(xfrmstr, NULL, 0);
strxfrm doesn't work that way (and if it did, it would give back a
malloc'd not a palloc'd string).
On Tue, 8 Jul 2003 11:40:15 -0600 (MDT) "scott.marlowe" <[EMAIL PROTECTED]> wrote:
> You may have a firewall setup to block all ports by default.
> firewall-config or something like it was the name of the firewall config
> util in 7.2.
in recent redhats, this is likely it.
sudo /sbin/ipchains
On Tuesday 08 Jul 2003 6:38 pm, Dragan Matic wrote:
>We were using Postgres 7.2.x and later 7.3.x under Red Hat 8, and
> everything worked fine. Clients are working under windows and are
> communicating to Postgres via ODBC.
Oh - one thing you need to know - there was an extra column introdu
On Tuesday 08 Jul 2003 6:38 pm, Dragan Matic wrote:
> Hi, there is a small problem here I have, I would appreciate any
> suggestion.
>
>We were using Postgres 7.2.x and later 7.3.x under Red Hat 8, and
> everything worked fine. Clients are working under windows and are
> communicating to Postg
On Tue, 8 Jul 2003, Dragan Matic wrote:
> Hi, there is a small problem here I have, I would appreciate any
> suggestion.
>
>We were using Postgres 7.2.x and later 7.3.x under Red Hat 8, and
> everything worked fine. Clients are working under windows and are
> communicating to Postgres via
Hi, there is a small problem here I have, I would appreciate any
suggestion.
We were using Postgres 7.2.x and later 7.3.x under Red Hat 8, and
everything worked fine. Clients are working under windows and are
communicating to Postgres via ODBC. This weekend we tried to upgrade to
Red Hat 9
On Tuesday 08 Jul 2003 5:55 pm, Bradley J. Bartram wrote:
> The first query is simple:
>
> SELECT a FROM table_a WHERE column_a = b
>
> This will return a single row. The next query takes that derived value and
> does a simliar select that returns multiple rows.
>
> SELECT c FROM table_b WHERE col
Hi, I have very interesting suspicion:
See my comments !
convert_string_datum
...
!this is my case
if (!lc_collate_is_c())
{
/* Guess that transformed string is not much bigger than
original */
xfrmsize = strlen(val) + 32;/* arbitrary pa
32 matches
Mail list logo
