Ühel kenal päeval, P, 2006-06-04 kell 18:09, kirjutas Tom Lane:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> >> Ühel kenal päeval, L, 2006-06-03 kell 10:43, kirjutas Jim Nasby:
> >>> Might also be worth adding analyze delay settings, ala
> >>> vacuum_co
On Thu, 2006-06-01 at 16:46 -0700, Mark Wong wrote:
> Simon Riggs wrote:
> > On Wed, 2006-05-10 at 09:55 -0700, Mark Wong wrote:
> >> Simon Riggs wrote:
> >>> Could you turn full_page_writes = off and do a few more tests? I think
> >>> the full page writes is swamping the xlog and masking the perfo
On 2006-06-02 21:26, Jim Nasby wrote:
> Now that we've got a nice amount of tuneability in the bgwriter, it
> would be nice if we had as much insight into how it's actually doing.
> I'd like to propose that the following info be added to the stats
> framework to assist in tuning it:
I'm intereste
On Jun 3, 2006, at 2:05 PM, Nicolai Petri wrote:
On Saturday 03 June 2006 17:27, Tom Lane wrote:
PFC <[EMAIL PROTECTED]> writes:
[snip - complicated update logic proprosal]
What do you think ?
Sounds enormously complicated and of very doubtful net win --- you're
[snip - ... bad i
On Jun 4, 2006, at 5:09 PM, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Hannu Krosing <[EMAIL PROTECTED]> writes:
Ühel kenal päeval, L, 2006-06-03 kell 10:43, kirjutas Jim Nasby:
Might also be worth adding analyze delay settings, ala
vacuum_cost_delay.
ANALYZE already respects th
On Jun 3, 2006, at 10:27 AM, Tom Lane wrote:
PFC <[EMAIL PROTECTED]> writes:
What do you think ?
Sounds enormously complicated and of very doubtful net win --- you're
moving a lot of overhead into SELECT in order to make UPDATE cheaper,
and on top of that the restriction to same-page
On Jun 4, 2006, at 8:18 AM, Andrew Dunstan wrote:
I said:
Another option would be to re-run cvs up one more time if we get any
unexpected files. It sounds like that would fix this issue on
windows
machines, while still ensuring we had a clean repo to work from.
please see the new release
Jim Nasby wrote:
What about my suggestion of runing CVS a second time if we get
extraneous files the first go-round? I'm guessing there'd have to be a
sleep in there as well...
The trouble with running "cvs update" a second time is that it will be
just as liable to fail as the first run. S
Sorry, it isn't mentioned on page, but this example of code working only with
before 8.1 versions. In 8.1 interface to dictionary was changed.
More precisely, in 8.1, lexize function (in num2english dlexize_num2english())
should return pointer to TSLexeme array instead of char**.
Rodrigo Hjor
Moving to -hackers
On Mon, Jun 05, 2006 at 12:32:38AM +0200, Zoltan Boszormenyi wrote:
> >I just noticed that psql's unformatted output uses too much
> >memory. Is it normal? It seems that psql draws all records
> >of a query off the server before it displays or writes the output.
> >I would expec
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I've been able to verify this on 8.1.4; psql -A -t -c 'SELECT * FROM
> largetable' > /dev/null results in psql consuming vast quantities of
> memory. Why is this?
Is it different without the -A?
I'm reading this as just another uninformed complaint abo
On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > I've been able to verify this on 8.1.4; psql -A -t -c 'SELECT * FROM
> > largetable' > /dev/null results in psql consuming vast quantities of
> > memory. Why is this?
>
> Is it different with
Teodor Sigaev wrote:
Sorry, it isn't mentioned on page, but this example of code working only
with before 8.1 versions. In 8.1 interface to dictionary was changed.
Try attached dict_tmpl.c
2Oleg: place file on site, pls
--
Teodor Sigaev E-mail: [EMAIL PROTE
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote:
>> I'm reading this as just another uninformed complaint about libpq's
>> habit of buffering the whole query result. It's possible that there's
>> a memory leak in the -A path specifically, but n
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote:
>>> I'm reading this as just another uninformed complaint about libpq's
>>> habit of buffering the whole query result. It's possible that there's
>>> a memory leak in the -A path specifically,
Mark Woodward wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote:
I'm reading this as just another uninformed complaint about libpq's
habit of buffering the whole query result. It's possible that there's
a memory leak in the -
Hi!
Tom Lane írta:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
I've been able to verify this on 8.1.4; psql -A -t -c 'SELECT * FROM
largetable' > /dev/null results in psql consuming vast quantities of
memory. Why is this?
Is it different without the -A?
I'm reading this as just anothe
> Mark Woodward wrote:
>>> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>>
On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote:
> I'm reading this as just another uninformed complaint about libpq's
> habit of buffering the whole query result. It's possible that
> there's
Mark Woodward wrote:
Wouldn't the "COPY (select ...) TO STDOUT" format being discussed solve
this for free?
It won't solve it in the general case for clients that expect a result
set. ISTM that "use a cursor" is a perfectly reasonable answer, though.
I'm not sure I a
Andrew Dunstan írta:
Mark Woodward wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote:
I'm reading this as just another uninformed complaint about libpq's
habit of buffering the whole query result. It's possible that
there's
On Mon, 2006-06-05 at 19:17 +0200, Zoltan Boszormenyi wrote:
> The general case cannot be applied for all particular cases.
> E.g. you cannot use cursors from shell scripts
This could be fixed by adding an option to psql to transparently produce
SELECT result sets via a cursor.
-Neil
-
Hi,I have two questions to ask:1. How to flush buffer in postgres? I'm not able to see the changes that I make in my code. Sometimes the output comes and sometime it's not. What might be the problem?
2. I have added a new field in RESDOM structure, made necessary
modifications in outfuncs.c, copy,
On Mon, Jun 05, 2006 at 11:24:09PM +0530, ranbeer makin wrote:
> Hi,
>
> I have two questions to ask:
>
> 1. How to flush buffer in postgres? I'm not able to see the changes that I
> make in my code. Sometimes the output comes and sometime it's not. What
> might be the problem?
How do you mean?
On 6/5/06, ranbeer makin <[EMAIL PROTECTED]> wrote:
1. How to flush buffer in postgres? I'm not able to see the changes that I
make in my code.
I assume you mean an output buffer? If you're using fprintf, make
sure to do a fflush. Otherwise, use elog(LOG or elog(DEBUG.
2. I have added a ne
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2006-06-05 at 19:17 +0200, Zoltan Boszormenyi wrote:
>> The general case cannot be applied for all particular cases.
>> E.g. you cannot use cursors from shell scripts
> This could be fixed by adding an option to psql to transparently produce
> SELE
Martijn van Oosterhout writes:
> On Mon, Jun 05, 2006 at 11:24:09PM +0530, ranbeer makin wrote:
>> 2. I have added a new field in RESDOM structure, made necessary
>> modifications in outfuncs.c, copy, read, equalfuncs.c but my prog is
>> behaving in a weird way, seems like some memory probs...
Jonah H. Harris wrote:
> > 2. I have added a new field in RESDOM structure, made necessary
> >modifications in outfuncs.c, copy, read, equalfuncs.c but my prog is
> >behaving in a weird way, seems like some memory probs...What other
> >modifications needs to be done to reflect the addition of
On 6/5/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
The word you've entered isn't in the dictionary.
Thanks Alvaro... my typing sometimes gets ahead of my in-brain spellcheck.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
On Mon, 5 Jun 2006, Teodor Sigaev wrote:
Teodor Sigaev wrote:
Sorry, it isn't mentioned on page, but this example of code working only
with before 8.1 versions. In 8.1 interface to dictionary was changed.
Try attached dict_tmpl.c
2Oleg: place file on site, pls
done
Regards,
Hi Hackers,
I'm rewriting fillfactor patch, per the following discussion,
http://archives.postgresql.org/pgsql-hackers/2006-03/msg00287.php
Now fillfactor can be set using WITH syntax:
- CREATE INDEX index ON table USING btree (columns) WITH (...)
- CREATE TABLE table (i integer PRIMARY KE
Just got this rather surprising result:
regression=# \timing
Timing is on.
regression=# explain analyze select * from tenk1 a join tenk1 b on a.unique1 =
b.unique2;
QUERY PLAN
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Now, I want to ask you how to modify WITH parameters for existing
> tables/indexes.
I'd go with the ALTER TABLE, rather than cluttering N other commands.
There's already precedent for delayed effects of parameter alterations
(SET, ALTER SET STATISTICS
32 matches
Mail list logo
