From: Pavan Deolasee [mailto:pavan.deola...@gmail.com]
Sent: Thursday, November 22, 2012 12:26 PM
To: Amit kapila
Cc: Jeff Janes; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [WIP PATCH] for Performance Improvement in Buffer
Management
On Mon, Nov 19, 2012 at 8:52 PM, Amit kapi
2012-11-22 08:35 keltezéssel, Boszormenyi Zoltan írta:
2012-11-21 22:15 keltezéssel, Magnus Hagander írta:
On Wed, Nov 21, 2012 at 10:01 PM, Boszormenyi Zoltan wrote:
Hi,
2012-11-21 19:19 keltezéssel, Magnus Hagander írta:
I'm breaking this out into it's own thread, for my own sanity if
not
After playing with some big SQLs for testing, I came to feel that
showing every remote query in EXPLAIN output is annoying, especially
when SELECT * is unfolded to long column list.
AFAIK no plan node shows so many information in a line, so I'm
inclined to make postgres_fdw to show it only when VE
2012/11/22 Shigeru Hanada :
> After playing with some big SQLs for testing, I came to feel that
> showing every remote query in EXPLAIN output is annoying, especially
> when SELECT * is unfolded to long column list.
>
> AFAIK no plan node shows so many information in a line, so I'm
> inclined to ma
Kohei KaiGai wrote:
> 2012/11/22 Shigeru Hanada :
>> After playing with some big SQLs for testing, I came to feel that
>> showing every remote query in EXPLAIN output is annoying, especially
>> when SELECT * is unfolded to long column list.
>>
>> AFAIK no plan node shows so many information in a li
Tom, Andrew,
We have the same issue in our product: Support UTF-8 on Windows.
You know certainly that UTF-8 code page (65001) is no supported by MS Windows
when you set the locale with setlocale(). You cannot rely on standard libc
functions such as isalpha(), mbtowc(), mbstowc(), wctomb(), wcsto
Hello Dimitri
* patching (success)
pavel ~/src/postgresql $ patch -p1 < binBUNnKQVPBP
patching file src/backend/catalog/heap.c
patching file src/backend/commands/event_trigger.c
patching file src/backend/commands/extension.c
patching file src/backend/commands/sequence.c
patching file src/backend/
sorry,There's a miss(with out free memory) in that patch sended just now,
and resend it.
Best Regards,
Chen Huajun
(2012/11/22 18:09), Chen Huajun wrote:
> hi
>
> I found a small bug in ecpg command and try to fix it.
> Please check if it is correct.
>
> When use a struct variable whose name l
Andrew Dunstan writes:
> Here is a WIP patch for enhancements to json generation.
>
> First, there is the much_requested json_agg, which will aggregate rows
> directly to json. So the following will now work:
>
> select json_agg(my_table) from mytable;
> select json_agg(q) from () q;
Awes
On Thu, Nov 22, 2012 at 10:16 AM, Boszormenyi Zoltan wrote:
> 2012-11-22 08:35 keltezéssel, Boszormenyi Zoltan írta:
>
>> 2012-11-21 22:15 keltezéssel, Magnus Hagander írta:
>>>
>>> On Wed, Nov 21, 2012 at 10:01 PM, Boszormenyi Zoltan
>>> wrote:
Hi,
2012-11-21 19:19 keltezésse
7;;
> > COPY TABLE TO PROGRAM 'command line';
I've reimplemented the feature. Attached is an updated version of the patch.
Todo:
* More documents
* More tests
Any comments are welcomed.
Thanks,
Best regards,
Etsuro Fujita
copy-popen-20121122.patch
Description:
Dimitri Fontaine-7 wrote
> You need to declare it in SQL, maybe like this: create function
> public.transform(text) returns text as '$libdir/fservice', 'transform'
> language C;
*I'm afraid that I won't do it becouse fservice.dll is writen in c++, but
dll file which contains function transform (
On Wednesday, November 21, 2012 11:36 PM Heikki Linnakangas wrote:
> On 20.11.2012 15:33, Amit Kapila wrote:
> > Defect-2:
> > 1. start primary A
> > 2. start standby B following A
> > 3. start cascade standby C following B.
> > 4. Start another standby D following C.
> > 5
On 11/22/2012 05:54 AM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Here is a WIP patch for enhancements to json generation.
First, there is the much_requested json_agg, which will aggregate rows
directly to json. So the following will now work:
select json_agg(my_table) from mytable
On Tuesday, November 20, 2012 7:21 PM Amit Kapila wrote:
On Monday, November 19, 2012 9:07 PM Amit Kapila wrote:
> On Monday, November 19, 2012 8:36 PM Alvaro Herrera wrote:
> > Amit Kapila escribió:
> >
> > > The only point I can see against SET PERSISTENT is that other
> variants
> > of
> > > SE
Greg Smith escribió:
> If I could just turn off logging just during those
> periods--basically, throwing them away only when some output rate
> throttled component hit its limit--I could still find them in the
> data collected the rest of the time. There are some types of
> problems that also onl
2012-11-22 12:44 keltezéssel, Magnus Hagander írta:
On Thu, Nov 22, 2012 at 10:16 AM, Boszormenyi Zoltan wrote:
2012-11-22 08:35 keltezéssel, Boszormenyi Zoltan írta:
2012-11-21 22:15 keltezéssel, Magnus Hagander írta:
On Wed, Nov 21, 2012 at 10:01 PM, Boszormenyi Zoltan
wrote:
Hi,
2012-1
When I was testing pg_resetxlog with relative database path,
The pg_resetxlog is doing the transaction log reset even when the server is
running.
Steps to reproduce:
1. ./pg_ctl -D ../../data start
2. ./pg_resetxlog -f ../../data -- is not able to detect as server
is already runn
On Thu, Nov 22, 2012 at 10:22 PM, Hari Babu wrote:
>
> When I was testing pg_resetxlog with relative database path,
> The pg_resetxlog is doing the transaction log reset even when the server is
> running.
>
> Steps to reproduce:
> 1. ./pg_ctl -D ../../data start
> 2. ./pg_resetxlog
Peter Eisentraut writes:
> On 11/21/12 9:42 AM, Robert Haas wrote:
>> On Mon, Nov 19, 2012 at 6:19 PM, Peter Eisentraut wrote:
>>> I continue to be of the opinion that allowing this second case to work
>>> is not desirable.
>> 1. Why?
> Because a strongly-typed system should not cast numbers to
Hi,
Thank you Pavel for reviewing my patch! :)
Pavel Stehule writes:
> * issues
>
> ** missing doc
Yes. I wanted to reach an agreement on why we need the de parsing for.
You can read the Last comment we made about it at the following link, I
didn't have any answer to my proposal.
http://arch
Hari Babu writes:
> When I was testing pg_resetxlog with relative database path,
> The pg_resetxlog is doing the transaction log reset even when the server is
> running.
Ooops. Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgs
On 21.11.2012 23:29, Alvaro Herrera wrote:
Alvaro Herrera escribió:
FWIW I have pushed this to github; see
https://github.com/alvherre/postgres/compare/bgworker
It's also attached.
The UnBlockSig stuff is the main stumbling block as I see it because it
precludes compilation on Windows. Maybe
On Thu, Nov 22, 2012 at 9:38 PM, Amit kapila wrote:
> Patch to implement SET PERSISTENT command is attached with this mail.
> Now it can be reviewed.
I got the following compile warnings:
xact.c:1847: warning: implicit declaration of function
'AtEOXact_UpdateAutoConfFiles'
guc.c:5134: warning: en
On Mon, Nov 19, 2012 at 7:55 PM, Alexander Korotkov
wrote:
> On Mon, Nov 19, 2012 at 10:05 AM, Alexander Korotkov
> wrote:
>>
>> On Thu, Nov 15, 2012 at 11:39 PM, Fujii Masao
>> wrote:
>>>
>>> Note that we cannot do a partial-match if KEEPONLYALNUM is disabled,
>>> i.e., if query key contains mu
On Mon, Nov 19, 2012 at 10:56 AM, Tomas Vondra wrote:
> I've done a quick review of the current patch:
Thanks for the commit!
As Alexander pointed out upthread, another infrastructure patch is required
before applying this patch. So I will implement the infra patch first.
Regards,
--
Fujii Ma
Heikki Linnakangas escribió:
> On 21.11.2012 23:29, Alvaro Herrera wrote:
> >Alvaro Herrera escribió:
> >>FWIW I have pushed this to github; see
> >>https://github.com/alvherre/postgres/compare/bgworker
> >>
> >>It's also attached.
> >>
> >>The UnBlockSig stuff is the main stumbling block as I see
Thanks for the review Pavel. I have taken care of the points you raised.
Please see the updated patch.
Regards,
--Asif
On Wed, Nov 21, 2012 at 1:47 AM, Pavel Stehule wrote:
> related to
> http://archives.postgresql.org/message-id/caauglxwpedfwae6dajmf7sxewfusa0f68p07retbbpf_fsa...@mail.gmail.com
On 22.11.2012 19:18, Alvaro Herrera wrote:
Heikki Linnakangas escribió:
On 21.11.2012 23:29, Alvaro Herrera wrote:
Alvaro Herrera escribió:
The UnBlockSig stuff is the main stumbling block as I see it because it
precludes compilation on Windows. Maybe we should fix that by providing
another f
On 21/11/12 20:39:01 mailto:cyril.vel...@metadys.com wrote:
> On 21/11/12 18:10:12, mailto:jeff.ja...@gmail.com wrote:
> > On Wed, Nov 21, 2012 at 8:51 AM, Cyril VELTER
> > wrote:
> > >
> > >After upgrading a pretty big database (serveral hundred gig) from 8.2
> > > to 9.2 I'm getting some
Heikki Linnakangas escribió:
> On 22.11.2012 19:18, Alvaro Herrera wrote:
> >Heikki Linnakangas escribió:
> >>On 21.11.2012 23:29, Alvaro Herrera wrote:
> >>>Alvaro Herrera escribió:
> The UnBlockSig stuff is the main stumbling block as I see it because it
> precludes compilation on Windows
On Tue, Nov 20, 2012 at 4:44 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
>> Agreed. Attached patch introduces the pgstatginindex() which now reports
>> GIN version number, number of pages in the pending list and number of
>> tuples in the pending list, as information about a GIN index.
>
> It seems fi
Hi Amit
I have reviewed and tested the patch, Following are my observations and
comments.
Basic stuff
-
- Patch applies OK
- Compiles cleanly with no warnings
- All regression tests pass.
Observations and Comments
---
- If no option is gi
On Thu, Nov 22, 2012 at 10:05 PM, Boszormenyi Zoltan wrote:
> 2012-11-22 12:44 keltezéssel, Magnus Hagander írta:
>>> Also, a question was buried in the other review which is - are we OK
>>> to remove the requiressl parameter. Both these patches do so, because
>>> the code becomes much
On Thu, Nov 22, 2012 at 2:05 PM, Amit Kapila wrote:
> ** **
>
>
> ** **
>
> >Sorry, I haven't followed this thread at all, but the numbers (43171 and
> 57920) in the last two runs of @mv-free-list for 32 clients look
> aberrations, no ? I wonder if *>*that's skewing the average.
>
> ** **
>
35 matches
Mail list logo