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
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
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
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,
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
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
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...
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
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
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?
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, 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
-
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
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
> 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
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
a memory leak in the -
> "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,
"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
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
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
"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
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
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
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
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
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 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 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 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 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
Ü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
32 matches
Mail list logo
