Would it be possible to look at a much larger number of samples during
analyze,
then look at the variation in those to generate a reasonable number of
pg_statistic "samples" to represent our estimate of the actual
distribution?
More datapoints for tables where the planner might benefit from
> > Cyril VELTER wrote:
>
> >
> > > Searching the source files, it seems the error message is generated in
> > > port/win32/socket.c line 594.
> >
> > Right, but the important thing is which path down to that function is it
> > generated in. Which is why a backtrace would help.
>
> Y
I think the general topic got lost in the weeds there...
But it would be helpful if you identified what you care about in a
database. That drives a lot of these decisions.
Example: My brother uses MySQL and I use Postgresql.
His reasons for MySQL:
More books on it at the bookstore.
It was a
Hello List!
I tried today to optmize in our companies internal Application the
querys. I come to a point where I tried, if querys with LIMIT are slower
then querys without limit
I tried following query in 8.2.4. Keep in mind that the table hs_company
only contains 10 rows.
[EMAIL PROTECTED
I think the quote() part for bytes is deprecated already?
my $string = "(" . join($glue, map{$dbh->quote($_,PG_BYTEA)} @
$tokens) . ")";
returns
Unknown type 17, defaulting to VARCHAR
as a warning...
On May 24, 2007, at 1:11 PM, [EMAIL PROTECTED] wrote:
Hi,
First, I would advise never
Thomas Munz wrote:
Hello List!
I tried today to optmize in our companies internal Application the
querys. I come to a point where I tried, if querys with LIMIT are slower
then querys without limit
I tried following query in 8.2.4. Keep in mind that the table hs_company
only contains 10 rows
Steve Atkins wrote:
Would it be possible to look at a much larger number of samples
during analyze,
then look at the variation in those to generate a reasonable number of
pg_statistic "samples" to represent our estimate of the actual
distribution?
More datapoints for tables where the planner
Well, I did another check on the LIMIT function ( table has without
"where" statment more then 2.000.000 entries) :
select count(*) from hd_conversation where action_int is null;
count
-
1652888
(1 row)
So, I runned this query now. The query with limit ( which eaven should
select 10
"Thomas Munz" <[EMAIL PROTECTED]> writes:
> 100.000 entries less then the second one )
> is much slower then selecting all entries. This query was also 100 times
> executed with allways the same result.
>
> explain ANALYZE select * from hd_conversation where action_int is null limit
> 1552888;expl
"Michael Harris \(BR/EPA\)" <[EMAIL PROTECTED]> writes:
> Whenever any kind of query is done on the table below, this is the
> result:
> ispdb_vxe=> select * from pm.carrier_on_13642;
> ERROR: cache lookup failed for type 0
Hmm, seems like something happened to your system catalogs, but where
ex
Francisco Reyes wrote:
Alban Hertroys writes:
I suppose you run those queries in a transaction block, right?
Correct.
Also I do a backup before doing the deletions.
Note that if you're in a transaction, you don't technically need the
backup (doesn't hurt though) as if you get it wrong you
On May 24, 2007, at 5:21 PM, Chris Browne wrote:
[EMAIL PROTECTED] ("A.M.") writes:
On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
[2] Nobody else has this, I believe, except possibly Ingres and
NonStop SQL. This means you can do a "
How can I reference any NEW field in an insert/update trigger function?
When someone inserts or updates any field with a single asterisk (*), I
need it to become '%%%'. But if they use an asterisk in any combination
with other fields, then I want to TRANSLATE those asterisks to a single
'%'.
I was
You don't use quote when using placeholders, but you will have to escape
the special characters, as mentioned previously.
The note in DBD:Pg perldoc that says this:
NOTE: The undocumented (and invalid) support for the
"SQL_BINARY"
data type is officially deprecated. Use "P
On Fri, 2007-05-25 at 11:17 -0400, Robert Fitzpatrick wrote:
> But if they use an asterisk in any combination
> with other fields
I meant to say 'But if they use an asterisk in any combination with
other *values* in the field...'. For instance, if they enter '*test*',
it will be TRANSLATE'd to '%
Robert Fitzpatrick wrote:
> How can I reference any NEW field in an insert/update trigger function?
> When someone inserts or updates any field with a single asterisk (*), I
> need it to become '%%%'. But if they use an asterisk in any combination
> with other fields, then I want to TRANSLATE those
Richard Huxton wrote:
Joseph Shraibman wrote:
I'm running:
PostgreSQL 8.2.3 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
My memory settings are:
work_mem = 64MB
shared_buffers = 128MB
temp_buffers = 32MB
I ran a query that was "SELECT field, cou
Joseph Shraibman wrote:
I ran a query that was "SELECT field, count(*) INTO TEMP temptable"
and it grew to be 10gig (as reported by top)
What was the real query?
First I selected 90634 rows (3 ints) into the first temp table, then I
did "select intfield1, count(intfield2) FROM realtable rt W
[EMAIL PROTECTED] (Erik Jones) writes:
> On May 24, 2007, at 5:21 PM, Chris Browne wrote:
>> Jan Wieck had a proposal to a similar effect, namely to give some way
>> to get one connection to duplicate the state of another one.
>>
>> This would permit doing a neat parallel decomposition of pg_dump:
On Fri, May 25, 2007 at 12:36:20PM -0400, Chris Browne wrote:
> We seem to be suffering, as the community, and patch queue, grows,
> from the problem that features that are regarded as being useful only
> to small sets of users are seeing greater reluctance for acceptance.
Another way of expressin
On Fri, 2007-05-25 at 12:00 -0400, Alvaro Herrera wrote:
> Robert Fitzpatrick wrote:
> > How can I reference any NEW field in an insert/update trigger function?
> > When someone inserts or updates any field with a single asterisk (*), I
> > need it to become '%%%'. But if they use an asterisk in an
Robert Fitzpatrick wrote:
> But still, how would I reference all fields using the pl/perl? Can I
> specify column numbers versus names as in '$_TD->{new}{1}' for the first
> column and loop or something? For instance, I would like to be able to
> say if any NEW column has a single asterisk only, s
Can I have 2 instance of postgres service running against same db???. I
meant 2 machine or the same machine with a 2 running executing postgres
process (if it is in the same machine, then through different ports),
working with the same db files, may be in a shared storage or any common
mounted f
On 25/05/2007 18:56, Arnaldo Gandol wrote:
Can I have 2 instance of postgres service running against same db???. I
meant 2 machine or the same machine with a 2 running executing postgres
process (if it is in the same machine, then through different ports),
AFAIK you can't, and trying to do so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/07 12:18, Andrew Sullivan wrote:
> On Fri, May 25, 2007 at 12:36:20PM -0400, Chris Browne wrote:
>> We seem to be suffering, as the community, and patch queue, grows,
>> from the problem that features that are regarded as being useful only
>>
Take a search through the archives for:
Fault Tolerant Postgresql (two machines, two postmasters, one disk array)
I recently posted this question and got a lot of good responses.
j
On Fri, 25 May 2007 18:59:34 +0100
Raymond O'Donnell <[EMAIL PROTECTED]> wrote:
> On 25/05/2007 18:56, Arnaldo Gand
On Fri, May 25, 2007 at 12:59:25PM -0500, Ron Johnson wrote:
> Except that seemingly "boutique" features can be road-blocks to
> implementing projects, which means that you never hear from them.
Yes. That's a risk that free software projects take, alas. If you
can't force your users to tell you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/07 13:09, Andrew Sullivan wrote:
> On Fri, May 25, 2007 at 12:59:25PM -0500, Ron Johnson wrote:
>> Except that seemingly "boutique" features can be road-blocks to
>> implementing projects, which means that you never hear from them.
>
> Yes.
Richard Huxton wrote:
Joseph Shraibman wrote:
I ran a query that was "SELECT field, count(*) INTO TEMP temptable"
and it grew to be 10gig (as reported by top)
What was the real query?
First I selected 90634 rows (3 ints) into the first temp table, then I
did "select intfield1, count(intfi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/07 12:59, Raymond O'Donnell wrote:
> On 25/05/2007 18:56, Arnaldo Gandol wrote:
>
>> Can I have 2 instance of postgres service running against same db???. I
>> meant 2 machine or the same machine with a 2 running executing postgres
>> proces
Joseph Shraibman wrote:
Richard Huxton wrote:
Joseph Shraibman wrote:
I ran a query that was "SELECT field, count(*) INTO TEMP temptable"
and it grew to be 10gig (as reported by top)
What was the real query?
First I selected 90634 rows (3 ints) into the first temp table, then
I did "sele
Richard Huxton <[EMAIL PROTECTED]> writes:
> Let's see if that hash-join is really the culprit. Can you run EXPLAIN
> and then EXPLAIN ANALYSE on the query, but first issue:
> SET enable_hashjoin=off;
> If that make little difference, try the same with enable_hashagg.
It seems like it must be the
On Fri, May 25, 2007 at 01:26:02PM -0500, Ron Johnson wrote:
> >> 1. transaction failure on statement failure[0], and
> >
> > I personally regard that as a feature, not a bug, so I'd be opposed
> > to changing it.
>
> Why? Not failing the whole transaction lets me decide how to handle
> that *on
On Fri, 2007-05-25 at 13:45 -0400, Alvaro Herrera wrote:
> Robert Fitzpatrick wrote:
>
> > But still, how would I reference all fields using the pl/perl? Can I
> > specify column numbers versus names as in '$_TD->{new}{1}' for the first
> > column and loop or something? For instance, I would like
On May 25, 2007, at 11:36 AM, Chris Browne wrote:
[EMAIL PROTECTED] (Erik Jones) writes:
On May 24, 2007, at 5:21 PM, Chris Browne wrote:
Jan Wieck had a proposal to a similar effect, namely to give some
way
to get one connection to duplicate the state of another one.
This would permit doin
Erik Jones wrote:
> And, to finish up, is there any reason that pg_restore couldn't
> already work with separate processes working in parallel?
The problem is that the ordering of objects in the dump is the only
thing that makes the dump consistent with regards to the dependencies of
objects.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Erik Jones wrote:
>> And, to finish up, is there any reason that pg_restore couldn't
>> already work with separate processes working in parallel?
> The problem is that the ordering of objects in the dump is the only
> thing that makes the dump consist
On Fri, May 25, 2007 at 05:28:43PM -0400, Tom Lane wrote:
> That's true at the level of DDL operations, but AFAIK we could
> parallelize table-loading and index-creation steps pretty effectively
> --- and that's where all the time goes.
I made a presentation at OSCON a few years ago about how we d
Hi Tom,
Thanks for your response.
None of the typeid atttypid fields were 0:
attrelid | attname | atttypid | attstattarget |
attlen | attnum | attndims | attcacheoff | atttypmod | attbyval |
attstorage | attalign | attnotnull | atthasdef | attisdropped |
attislocal | attinhcou
"Michael Harris \(BR/EPA\)" <[EMAIL PROTECTED]> writes:
> None of the typeid atttypid fields were 0:
Hmm, but you've got a couple of bigint-array columns:
>167581 | pmtransmittedcarrierpower | 1016 |-1 |
> -1 | 4 |0 | -1 |-1 | f| x
> | d
Hi Tom,
Hmm .. Interesting. A few weeks back I had a corrupted table (due to a
disk error). I temporarily set zero_damaged_pages and vacuumed the
tables concerned. Now that I look back through the logs, the affected
table was utrancell_oo_13642. The fact that the number on the end was
the same mea
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Erik Jones wrote:
>
>> And, to finish up, is there any reason that pg_restore couldn't
>> already work with separate processes working in parallel?
>
> The problem is that the ordering of objects in the dump is the only
> thing that makes the dump cons
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/07 23:02, Chris Browne wrote:
> [EMAIL PROTECTED] (Alvaro Herrera) writes:
>> Erik Jones wrote:
>>
>>> And, to finish up, is there any reason that pg_restore couldn't
>>> already work with separate processes working in parallel?
>> The probl
43 matches
Mail list logo
