Hello,
> Agree that windowing function will return all the rows compared to max and
> group by returing only max rows per group. But even while arriving at the
> aggregate/sorting windowing function seems to spend more effort than group
> by/order by.
(I'll apologise in advance for possible misr
On Fri, Oct 25, 2013 at 5:57 AM, Magnus Hagander wrote:
> In fact I've been considering suggesting we might want to retire the
> difference between archive and hot_standby as wal_level, because the
> difference is usually so small. And the advantage of hot_standby is in
> almost every case worth i
On 2013-10-24 17:17:22 -0700, Josh Berkus wrote:
> On 10/24/2013 04:55 PM, Robert Haas wrote:
> > On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
> >> On 10/23/2013 09:58 PM, Amit Kapila wrote:
> >>> I wonder why anyone would like to freeze during CLUSTER command when
> >>> they already have s
Hi,
On Thu, Oct 24, 2013 at 5:59 PM, Haribabu kommi
wrote:
> Here I have added some more regression tests to improve the missing function
> coverage of schemacmds.c, user.c and tablespace.c.
> The added tests are mainly RENAME TO and OWNER TO support.
Could you add those patches to the next comm
On Fri, Oct 25, 2013 at 4:29 AM, Thomas Munro wrote:
> On 24 October 2013 05:58, Amit Kapila wrote:
>>
>> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
>> > Hi
>> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
>> > add
>> > that, for consistency with VACUUM. I
On Thu, Oct 24, 2013 at 10:39 PM, Josh Berkus wrote:
> On 10/23/2013 09:58 PM, Amit Kapila wrote:
>> I wonder why anyone would like to freeze during CLUSTER command when
>> they already have separate way (VACUUM FREEZE) to achieve it, do you
>> know or can think of any case where user wants to do
On Thu, Oct 24, 2013 at 8:37 PM, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao wrote:
>> So, our consensus is to introduce the hooks for FPW compression so that
>> users can freely select their own best compression algorithm?
>> Also, probably we need to implement at least on
Peter Eisentraut writes:
> Move rmtree() from libpgport to libpgcommon
This patch leaves dirmod.c entirely empty on non-Windows platforms.
At least on my OS X Lion laptop, that results in some bleating:
/usr/bin/ranlib: file: libpgport.a(dirmod.o) has no symbols
/usr/bin/ranlib: file: libpgport_
Robert Haas writes:
> I wonder if we should go so far as to make this the default behavior,
> instead of just making it an option.
In that case you'd have to invent a NOFREEZE keyword, no? Ick.
In any case, it's very far from obvious to me that CLUSTER ought
to throw away information by default
On Fri, Oct 25, 2013 at 5:57 AM, Magnus Hagander wrote:
> On Thu, Oct 24, 2013 at 10:51 PM, Josh Berkus wrote:
>> On 10/24/2013 01:14 PM, Heikki Linnakangas wrote:
>>
>> I think it would be worth estimating what this actually looks like in
>> terms of log write quantity. My inclication is to say
Robert Haas writes:
> On Thu, Oct 24, 2013 at 2:18 PM, Peter Eisentraut wrote:
>> While this is attractive, the same logic would suggest that we rename
>> pg_malloc() to palloc(), and that sounds wrong. The frontend and
>> backend functions do have different freeing semantics.
> I'd almost be i
On 10/24/2013 04:55 PM, Robert Haas wrote:
> On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
>> On 10/23/2013 09:58 PM, Amit Kapila wrote:
>>> I wonder why anyone would like to freeze during CLUSTER command when
>>> they already have separate way (VACUUM FREEZE) to achieve it, do you
>>> know
On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
> On 10/23/2013 09:58 PM, Amit Kapila wrote:
>> I wonder why anyone would like to freeze during CLUSTER command when
>> they already have separate way (VACUUM FREEZE) to achieve it, do you
>> know or can think of any case where user wants to do i
On 24 October 2013 05:58, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
> > Hi
> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
> add
> > that, for consistency with VACUUM. Is it useful?
>
> I wonder why anyone would like to freeze during
On 10/24/2013 02:36 PM, Peter Eisentraut wrote:
> On 10/22/13, 2:27 PM, Josh Berkus wrote:
>> pg_partman has several external (python) scripts which help the
>> extension, located in /extras/ in its source. The problem currently is
>> that if you install pg_partman via pgxn or package, you don't g
On 10/22/13, 2:27 PM, Josh Berkus wrote:
> pg_partman has several external (python) scripts which help the
> extension, located in /extras/ in its source. The problem currently is
> that if you install pg_partman via pgxn or package, you don't get those
> scripts, because there's no "install" loca
On Thu, Oct 24, 2013 at 10:51 PM, Josh Berkus wrote:
> On 10/24/2013 01:14 PM, Heikki Linnakangas wrote:
>> One extra WAL record whenever a hint bit is set on a page, for the first
>> time after a checkpoint. In other words, a WAL record needs to be
>> written in the same circumstances as with pag
On Thu, Oct 24, 2013 at 2:18 PM, Peter Eisentraut wrote:
> On 10/22/13, 3:40 PM, Tom Lane wrote:
>> In order to avoid having to clutter stuff like that with #ifdef FRONTENDs,
>> I'm now thinking we should use exactly the same names for the frontend and
>> backend versions, ie psprintf() and pvspri
On 10/24/2013 01:14 PM, Heikki Linnakangas wrote:
> One extra WAL record whenever a hint bit is set on a page, for the first
> time after a checkpoint. In other words, a WAL record needs to be
> written in the same circumstances as with page checksums, but the WAL
> records are much smaller as they
On 24.10.2013 23:07, Josh Berkus wrote:
On 10/24/2013 11:12 AM, Heikki Linnakangas wrote:
On 24.10.2013 20:39, Josh Berkus wrote:
On 10/24/2013 04:15 AM, Pavan Deolasee wrote:
If we do what you are suggesting, it seems like a single line patch
to me.
In XLogSaveBufferForHint(), we probably nee
On 10/24/2013 11:12 AM, Heikki Linnakangas wrote:
> On 24.10.2013 20:39, Josh Berkus wrote:
>> On 10/24/2013 04:15 AM, Pavan Deolasee wrote:
>>> If we do what you are suggesting, it seems like a single line patch
>>> to me.
>>> In XLogSaveBufferForHint(), we probably need to look at this
>>> additi
On 24 October 2013 18:28, Andres Freund wrote:
> On 2013-10-23 21:20:58 +0100, Dean Rasheed wrote:
>> On 23 October 2013 21:08, Andres Freund wrote:
>> > On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote:
>> >> Hmm, my first thought is that rewriteTargetView() should be calling
>> >> AcquireRewrit
On Thu, Oct 24, 2013 at 5:41 AM, Thom Brown wrote:
> On 5 September 2013 22:24, Bruce Momjian wrote:
>> On Mon, Aug 19, 2013 at 09:27:57PM -0400, Stephen Frost wrote:
>>> * Andres Freund (and...@2ndquadrant.com) wrote:
>>> > I vote for adapting the patch to additionally zero out the file via
>>>
On 10/24/13, 2:37 PM, Magnus Hagander wrote:
> They're not causing compiler warnings when you just build with gssapi,
> correct? Only if you enable the native krb5?
Well, actually I was just about to reply that gssapi is also deprecated.
They want you to use some framework instead.
That's someth
On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut wrote:
> On 10/18/12, 7:20 AM, Magnus Hagander wrote:
>> 1. krb5 authentication. We've had gssapi since 8.3 (which means in all
>> supported versions). krb5 has been deprecated, also since 8.3. Time to
>> remove it?
>
> OS X Mavericks has now marke
On 10/18/12, 7:20 AM, Magnus Hagander wrote:
> 1. krb5 authentication. We've had gssapi since 8.3 (which means in all
> supported versions). krb5 has been deprecated, also since 8.3. Time to
> remove it?
OS X Mavericks has now marked just about everything in krb5.h as
deprecated, leading to compil
Peter Eisentraut writes:
> On 10/22/13, 3:40 PM, Tom Lane wrote:
>> In order to avoid having to clutter stuff like that with #ifdef FRONTENDs,
>> I'm now thinking we should use exactly the same names for the frontend and
>> backend versions, ie psprintf() and pvsprintf(). The main reason for
>> c
On 10/22/13, 3:40 PM, Tom Lane wrote:
> In order to avoid having to clutter stuff like that with #ifdef FRONTENDs,
> I'm now thinking we should use exactly the same names for the frontend and
> backend versions, ie psprintf() and pvsprintf(). The main reason for
> considering a pg_ prefix for the
On 24.10.2013 20:39, Josh Berkus wrote:
On 10/24/2013 04:15 AM, Pavan Deolasee wrote:
If we do what you are suggesting, it seems like a single line patch to me.
In XLogSaveBufferForHint(), we probably need to look at this additional GUC
to decide whether or not to backup the block.
Wait, what?
On 10/24/2013 04:15 AM, Pavan Deolasee wrote:
> If we do what you are suggesting, it seems like a single line patch to me.
> In XLogSaveBufferForHint(), we probably need to look at this additional GUC
> to decide whether or not to backup the block.
Wait, what? Why are we having an additional GUC?
On 2013-10-23 21:20:58 +0100, Dean Rasheed wrote:
> On 23 October 2013 21:08, Andres Freund wrote:
> > On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote:
> >> Hmm, my first thought is that rewriteTargetView() should be calling
> >> AcquireRewriteLocks() on viewquery, before doing too much with it.
On Thu, Oct 24, 2013 at 1:13 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
Would this make sense as a configure-time check, rather than initdb, to
try blocking SIGSYS and checking f
On 2013-10-24 13:13:23 -0400, Tom Lane wrote:
> Stephen Frost writes:
> The above patch ignores SIGSYS throughout initdb. We could narrow the
> possible side-effects by only disabling SIGSYS around the shm_open call,
> but I'm not sure there's any value in that. It seems likely to me that
> the
On Thu, Oct 24, 2013 at 12:22:59PM -0400, Robert Haas wrote:
> On Thu, Oct 24, 2013 at 11:40 AM, k...@rice.edu wrote:
> > On Thu, Oct 24, 2013 at 11:07:38AM -0400, Robert Haas wrote:
> >> On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao
> >> wrote:
> >> > So, our consensus is to introduce the hooks
On Thu, Oct 24, 2013 at 1:00 PM, Andres Freund wrote:
> On 2013-10-24 16:06:19 +0300, Heikki Linnakangas wrote:
>> On 24.10.2013 09:03, Abhijit Menon-Sen wrote:
>> >One open question is what to do about rounding up the size. It should
>> >not be necessary, but for the fairly recent bug described a
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
>>> Would this make sense as a configure-time check, rather than initdb, to
>>> try blocking SIGSYS and checking for an ENOSYS from shm_open()? Seems
>>> preferrable to
On 10/23/2013 08:52 PM, Alvaro Herrera wrote:
> Peter Geoghegan escribió:
>
>> I am interested in making it store richer statistics,
>> provided we're very careful about the costs. Every time those counters
>> are incremented, a spinlock is held.
>
> Hmm, now if we had portable atomic addition, s
On 10/23/2013 09:58 PM, Amit Kapila wrote:
> I wonder why anyone would like to freeze during CLUSTER command when
> they already have separate way (VACUUM FREEZE) to achieve it, do you
> know or can think of any case where user wants to do it along with
> Cluster command?
"If I'm rewriting the tab
On 2013-10-24 16:06:19 +0300, Heikki Linnakangas wrote:
> On 24.10.2013 09:03, Abhijit Menon-Sen wrote:
> >One open question is what to do about rounding up the size. It should
> >not be necessary, but for the fairly recent bug described at the link
> >in the comment (https://bugzilla.kernel.org/sh
On Thu, Oct 24, 2013 at 11:40 AM, k...@rice.edu wrote:
> On Thu, Oct 24, 2013 at 11:07:38AM -0400, Robert Haas wrote:
>> On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao wrote:
>> > So, our consensus is to introduce the hooks for FPW compression so that
>> > users can freely select their own best co
On Thu, Oct 24, 2013 at 11:07:38AM -0400, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao wrote:
> > So, our consensus is to introduce the hooks for FPW compression so that
> > users can freely select their own best compression algorithm?
> > Also, probably we need to implement
Robert Haas writes:
> On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao wrote:
>> So, our consensus is to introduce the hooks for FPW compression so that
>> users can freely select their own best compression algorithm?
>> Also, probably we need to implement at least one compression contrib module
>>
2013/10/24 Robert Haas
> On Tue, Oct 22, 2013 at 9:37 PM, Josh Kupershmidt
> wrote:
> > On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt
> wrote:
> >> Also, Pavel, this patch is still listed as 'Needs Review' in the CF
> >> app, but I haven't seen a response to the concerns in my last message.
On Tue, Oct 22, 2013 at 9:37 PM, Josh Kupershmidt wrote:
> On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt wrote:
>> Also, Pavel, this patch is still listed as 'Needs Review' in the CF
>> app, but I haven't seen a response to the concerns in my last message.
>
> It looks like this patch has bee
On Thu, Oct 24, 2013 at 9:06 AM, Heikki Linnakangas
wrote:
> * the documentation should perhaps mention that the setting only has an
> effect if POSIX shared memory is used. That's the default on Linux, but we
> will try to fall back to SystemV shared memory if it fails.
This is true for dynamic
On Mon, Oct 21, 2013 at 11:52 PM, Fujii Masao wrote:
> So, our consensus is to introduce the hooks for FPW compression so that
> users can freely select their own best compression algorithm?
> Also, probably we need to implement at least one compression contrib module
> using that hook, maybe it's
On Tue, Oct 22, 2013 at 2:13 PM, Andres Freund wrote:
> On 2013-10-22 13:57:53 -0400, Robert Haas wrote:
>> On Tue, Oct 22, 2013 at 1:08 PM, Andres Freund
>> wrote:
>> >> That strikes me as a flaw in the implementation rather than the idea.
>> >> You're presupposing a patch where the necessary i
On Thu, Oct 24, 2013 at 6:54 AM, Andrew Dunstan wrote:
> I'll be quite happy if we can get around the query text length limit. I have
> greatly increased the buffer size at quite a few clients, in one case where
> they run some pretty large auto-generated queries and have memory to burn,
> up to 4
Pavan Deolasee escribió:
> Yeah, I had brought up similar idea up thread. Right now wal_level is
> nicely ordered. But with this additional logic, I am not sure if we would
> need multiple new levels and also break that ordering (I don't know if its
> important). For example, one may want to set u
On 22.10.2013 13:55, Pavel Stehule wrote:
2013/10/21 Noah Misch
If you're prepared to change the function names and add the subset-oriented
functions, I would appreciate that.
here is patch
lobj.sgml still refer to the old names.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 10/23/2013 07:51 PM, Peter Geoghegan wrote:
On Wed, Oct 23, 2013 at 4:46 PM, Josh Berkus wrote:
So you're suggesting that instead of storing the aggregates as we
currently do, we store a buffer of the last N queries (in normal form)
and their stats? And then aggregate when the user asks fo
Andres Freund writes:
> FWIW, I've repeatedly now thought that it'd make maintaining/updating
> patches easier if we switched that query into unaligned tuple only (\a
> \t) mode. That would remove the frequent conflicts on the row count and
> widespread changes due to changed alignment.
> Alternat
On Thu, Oct 24, 2013 at 10:28:43AM +0530, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
> > Hi
> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add
> > that, for consistency with VACUUM. Is it useful?
>
> I wonder why anyone would like to f
On 24.10.2013 09:03, Abhijit Menon-Sen wrote:
This is a slightly reworked version of the patch submitted by Richard
Poole last month, which was based on Christian Kruse's earlier patch.
Thanks.
With huge_tlb_pages=off, this is the best result I got:
tps = 8680.771068 (including connecti
On Thu, Oct 24, 2013 at 5:45 PM, Heikki Linnakangas wrote:
>
>>
> Will just have to figure out what we want the user interface to be like;
> should it be a separate guc, or somehow cram it into wal_level?
>
>
Yeah, I had brought up similar idea up thread. Right now wal_level is
nicely ordered. B
On 24.10.2013 14:15, Pavan Deolasee wrote:
On Thu, Oct 24, 2013 at 4:22 PM, Heikki Linnakangas
wrote:
To fix that, pg_rewind could always start the rewinding process from the
last checkpoint before the point that the histories diverge, instead of the
exact point of divergence.
Is that someth
On Thu, Oct 24, 2013 at 4:45 PM, Pavan Deolasee wrote:
> . Or would the recovery logic apply first WAL without looking at the page
> lsn ? (Sorry, may be I should read the code instead of asking you)
>
>
Never mind. I realized it has to. That's the whole purpose of backing it up
in the first place
On Thu, Oct 24, 2013 at 4:22 PM, Heikki Linnakangas wrote:
> .
>>
>
> To fix that, pg_rewind could always start the rewinding process from the
> last checkpoint before the point that the histories diverge, instead of the
> exact point of divergence.
Is that something required even if someone pl
On 24.10.2013 13:20, Haribabu kommi wrote:
There is an ident context leak which is occurs during reload of configuration
files when
there is no ident configuration items are present in the configuration file.
In function load_ident(), New context is allocated to store the
new_parsed_lines and
On 24.10.2013 13:02, Pavan Deolasee wrote:
Another difference AFAICS is that checksum feature needs the block to be
backed up only after the first time a hint bit is updated after checkpoint.
But for something like pg_rewind to work, we will need to WAL log every
hint bit update on a page. So we
On 5 September 2013 22:24, Bruce Momjian wrote:
> On Mon, Aug 19, 2013 at 09:27:57PM -0400, Stephen Frost wrote:
>> * Andres Freund (and...@2ndquadrant.com) wrote:
>> > I vote for adapting the patch to additionally zero out the file via
>> > write(). In your tests that seemed to perform at least a
Hello, Sorry that it's been a while..
1. Observed symptom
As you know, UNION ALL accompanied with ORDER BY uses indexes if
available.
> uniontest=# EXPLAIN SELECT * FROM c11 UNION ALL SELECT * FROM c12 ORDER BY a;
>QUERY PLAN
>
There is an ident context leak which is occurs during reload of configuration
files when
there is no ident configuration items are present in the configuration file.
In function load_ident(), New context is allocated to store the
new_parsed_lines and deletes
the old context when parsed_ident_lin
On Mon, Oct 21, 2013 at 7:10 PM, Sawada Masahiko wrote:
>
>
> I agree with you.
> If writing FPW is not large performance degradation, it is just idea
> that we can use to write FPW in same timing as checksum enabled.
> i.g., if we support new wal_level, the system writes FPW when a simple
> SELEC
Here I have added some more regression tests to improve the missing function
coverage of
schemacmds.c, user.c and tablespace.c.
The added tests are mainly RENAME TO and OWNER TO support.
patches are attached in the mail.
please check and provide your suggestions.
Regards,
Hari babu.
schema_u
On 2013-10-23 20:50:30 -0400, Tom Lane wrote:
> Mike Blackwell writes:
> > While reviewing the Network Stats Traffic patch I discovered the current
> > regression test for rules depends on the system view definitions not
> > changing:
>
> Yes, this is standard. We just update the expected output
Hi,
On 2013-10-24 00:28:44 +0100, Thomas Munro wrote:
> I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
> add that, for consistency with VACUUM. Is it useful?
I think you'd need to prevent that form from working on system catalogs
- xmin has a meaning there sometimes (e.
On 24 October 2013 05:58, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
>> Hi
>> I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add
>> that, for consistency with VACUUM. Is it useful?
>
> I wonder why anyone would like to freeze during CLUSTE
68 matches
Mail list logo
