On Mon, May 18, 2009 at 3:10 AM, Itagaki
Takahiro wrote:
>
> The attached is a patch to execute lo_unlink() before lo_create()
> in pg_restore.
the patch applies almost cleanly (there are only minor and superfluos
hunks), compiles...
it works as expected...
this patch makes me wonder why we dump
2009/7/18 Kevin Grittner :
> Pavel Stehule wrote:
>
>> table was filled with random numbers and analyzed - you can simple
>> check it - look on begin of the thread. This table wasn't updated.
>
> Confirmed. The ORDER BY consistently speeds up the query. Odd
>
> Sort speed varied based on ran
On Fri, Jul 17, 2009 at 3:30 PM, Jaime
Casanova wrote:
>>
>> i wasn't able to repeat this on a new instalation and of
>> course i can't swear this is your patch fault...
>>
> this is not your patch fault but an existing bug, i repeat that
> behaviour in an unpatched source tree...
>
ok, i reproduc
OK, if you untar the attached in the docs dir there are a three separate
sets of changes in it. It all functions, but consider it a discussion
point rather than a patch. Presumably we'd need to discuss a patch over
on the docs mailing-list.
1. Fixed navigation
Copy STYLING/stylesheet.css over
On Fri, Jul 17, 2009 at 10:42:02AM +0300, Peter Eisentraut wrote:
> On Tuesday 07 July 2009 23:31:54 Marko Tiikkaja wrote:
> > Here's a patch(WIP) that implements INSERT .. RETURNING inside a CTE.
>
> Could you supply some test cases to illustrate what this patch accomplishes?
postgres:54321=# CR
On Fri, Jul 17, 2009 at 04:13:58PM -0700, David Fetter wrote:
> On Fri, Jul 17, 2009 at 10:36:14AM -0700, Joshua D. Drake wrote:
> > On Thu, 2009-07-16 at 21:31 -0700, Josh Berkus wrote:
> > > Robert,
> > >
> > > BTW, the new commitfest software is great. Easily a 75%
> > > reduction in time requ
Joshua Tolley wrote:
I don't know how patches that require catalog version changes are generally
handled; should the patch include that change?
The committer should handle that.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Jul 14, 2009 at 11:10:00PM +0200, Petr Jelinek wrote:
> Hello,
>
> this is first public version of our DefaultACLs patch as described on
> http://wiki.postgresql.org/wiki/DefaultACL .
Ok, here's my first crack at a comprehensive review. There's more I need to
look at, eventually. Some of
Tom Lane wrote:
Greg Stark writes:
Really? That's not how I read it. I read it as the build process in
the contrib directory built these modules using the pgxs configuration
from his 8.3 install.
Hm, maybe, but it's not supposed to do that (and I would think we'd have
noticed such a
Greg Stark writes:
> Really? That's not how I read it. I read it as the build process in
> the contrib directory built these modules using the pgxs configuration
> from his 8.3 install.
Hm, maybe, but it's not supposed to do that (and I would think we'd have
noticed such a problem before --- sure
On Sat, Jul 18, 2009 at 12:30 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> ERROR: incompatible library
>> "/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so": version mismatch
>> DETAIL: Server is version 8.4, library is version 8.3.
>
> That's just bizarre. Could you try strace'i
On Fri, Jul 17, 2009 at 10:36:14AM -0700, Joshua D. Drake wrote:
> On Thu, 2009-07-16 at 21:31 -0700, Josh Berkus wrote:
> > Robert,
> >
> > BTW, the new commitfest software is great. Easily a 75% reduction in
> > time required to track reviewing activity.
>
> I agree. It is much better. I have
I've just had a case of the 'could not reattach to shared memory'
problem, and I thought I'd pass on my findings in case it helps.
I found that it was trying to access shared memory at 0x161
I used Process Explorer to have a look at the DLLs used by existing
copies of Postgres to see if I cou
Folks,
I was just looking over the commitfest, and wanted to be able to sort
tables. Fortunately, Somebody Else(TM) has already written and tested
the code.
Please find enclosed a patch to do same.
It's untested because I couldn't quite figure out what to install and
configure in order to test
To more clearly identify that pg_migrator now has known bugs, I have
released pg_migrator 8.4.1 alpha1, and mentioned in the README that
there are known bugs related to migrating sequences and large objects.
I have removed the 8.4 source file from pgfoundry.
-
"Kevin Grittner" writes:
> ERROR: incompatible library
> "/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so": version mismatch
> DETAIL: Server is version 8.4, library is version 8.3.
That's just bizarre. Could you try strace'ing the backend while doing
that CREATE FUNCTION command (o
On Jul 17, 2009, at 11:56 AM, Bernd Helmle wrote:
it seems there's something broken, patch complains about a broken
format. Can you please provide a new diff file?
Sorry about that--probably got messed up as I pasted it into the
message. I've attached the patch this time.
plpgsql_keyword
Kevin Grittner wrote:
I took the 8.4.0 release tarball and tried to build it on one of our
production servers which is currently running 8.3.7. We routinely
build multiple versions of PostgreSQL on a machine, using --prefix to
place them. Something seems broken for 8.4.0. Not sure how best to
I took the 8.4.0 release tarball and tried to build it on one of our
production servers which is currently running 8.3.7. We routinely
build multiple versions of PostgreSQL on a machine, using --prefix to
place them. Something seems broken for 8.4.0. Not sure how best to
proceed.
I ran:
On Fri, Jul 17, 2009 at 2:45 PM, Greg Stark wrote:
> Neat! I haven't read the patch yet but I have some questions.
>
> Does this handle the case where some partitions have an index and
> others don't? Ie. Does it just apply the regular optimization to each
> partition and then slap on the aggrega
On Fri, Jul 17, 2009 at 10:34:34AM -0500, Campbell, Lance wrote:
>
> I use postgres 8.1.X.
>
> Is there a way to add code completion when entering:
>
> set search_path = xyz
>
> I love the code completion for SQL. It would be really nice to have
> it for the "set search_path".
>
> Thanks
Neat! I haven't read the patch yet but I have some questions.
Does this handle the case where some partitions have an index and
others don't? Ie. Does it just apply the regular optimization to each
partition and then slap on the aggregate node? I think that's actually
a realistic case because peop
Fujii Masao wrote:
> http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php
>
> In line with Robert's suggestion, I submit non-blocking pqcomm patch
> as a self-contained one.
>
Here's my initial review of the non-blocking pqcomm patch. The patch applies
cleanly and passes regression.
"Dickson S. Guedes" writes:
> Em Thu, 16 Jul 2009 17:40:45 -0300, Peter Eisentraut
> escreveu:
>> More generally, does anyone actually need this feature? psql complains
>> loudly enough if the version numbers are not the right ones. I don't
>> know why this would need to be repeated in th
Hi,
attached you can find a very small patch for the help in psql (\?). It's
possible to use \du also as \du+ . The [+] was missing in help.
I was asking about this at the general list and Peter E. was asking me
to provide a patch. I sent the patch there but realized now, that this
was the w
Laurent Laborde wrote:
> What about SET STORAGE MAIN then ? To prevent out-of-line storage ?
Well, that doesn't try as hard as you might think to keep from storing
data out-of-line. It uses the same threshold as the default EXTENDED
storage, but saves the out-of-line option for such columns
On Fri, Jul 17, 2009 at 10:40 PM, Kevin
Grittner wrote:
> Laurent Laborde wrote:
>
>> But... on which version are you planning to do that ?
>
> The patch, if there's consensus that it's a good idea, would be for
> 8.5. Since it is new functionality, there wouldn't be a back-port to
> prior releas
--On Freitag, Juli 17, 2009 12:05:46 -0700 Joe Conway
wrote:
Is there a way for me to extract the patch as the original attachment,
or am I supposed to just cat-n-paste into an editor to create one?
This has bitten me one or two times in the past, too. Fortunately i archive
all emails on l
Laurent Laborde wrote:
> Kevin Grittner wrote:
>> How about two new ALTER TABLE actions:
>>
>> ALTER [ COLUMN ] column SET COMPRESSION_THRESHOLD integer
>> ALTER [ COLUMN ] column SET EXTERNAL_THRESHOLD integer
>> Laurent, would something like this address your needs?
> Certainly !
> We
Consider the following schema:
create table foo_archive (a int, b timestamp);
create index foo_archive_idx on foo_archive(b);
CREATE TABLE foo_archive_2007_01_01 (CONSTRAINT
foo_archive_2007_01_01_b_check CHECK (((b >= '2007-01-01'::date) AND (b <
'2007-01-02'::date INHERITS (foo_a
Em Thu, 16 Jul 2009 17:40:45 -0300, Peter Eisentraut
escreveu:
On Thursday 07 May 2009 05:23:41 Dickson S. Guedes wrote:
This is a WIP patch (for the TODO item in the subject) that I'm putting
in the Commit Fest queue for 8.5.
More generally, does anyone actually need this feature? psql c
On Fri, Jul 17, 2009 at 1:44 PM, Jaime
Casanova wrote:
>
> i wasn't able to repeat this on a new instalation and of
> course i can't swear this is your patch fault...
>
this is not your patch fault but an existing bug, i repeat that
behaviour in an unpatched source tree...
with the steps in the p
During the review of the patch about improved PL/Python data type support, I
figured this could be somewhat simplified if PL/Python used the errcontext()
mechanisms instead of passing the function name around everywhere in order to
use it in error messages.
I have produced the attached patch.
On Fri, Jul 17, 2009 at 9:21 PM, Kevin
Grittner wrote:
> "Joshua D. Drake" wrote:
>> On Fri, 2009-07-17 at 12:50 -0500, Kevin Grittner wrote:
>
>>> (3) Allow override of the thresholds for individual columns.
>
>> I would skip 1 and 2 and have (3).
>
> Sure, pick the one which requires new syntax
On Tue, Jul 14, 2009 at 11:10:00PM +0200, Petr Jelinek wrote:
> Hello,
>
> this is first public version of our DefaultACLs patch as described on
> http://wiki.postgresql.org/wiki/DefaultACL .
I've been asked to review this. I can't get it to build, because of a missing
semicolon on line 1608. I
I've been looking into Frank van Vugt's report here:
http://archives.postgresql.org/pgsql-bugs/2009-07/msg00222.php
The cause of the problem is that while printing the value of the
ROW(NEW.*) expression, we acquire a tupledesc refcount on the
table's rowtype descriptor, and this refcount is assign
On Fri, 2009-07-17 at 14:21 -0500, Kevin Grittner wrote:
> "Joshua D. Drake" wrote:
> > On Fri, 2009-07-17 at 12:50 -0500, Kevin Grittner wrote:
>
> >> (3) Allow override of the thresholds for individual columns.
>
> > I would skip 1 and 2 and have (3).
>
> Sure, pick the one which require
"Joshua D. Drake" wrote:
> On Fri, 2009-07-17 at 12:50 -0500, Kevin Grittner wrote:
>> (3) Allow override of the thresholds for individual columns.
> I would skip 1 and 2 and have (3).
Sure, pick the one which requires new syntax! ;-)
How about two new ALTER TABLE actions:
ALTER [
decibel wrote:
> Here's an off-the-wall thought... since most of the CPU time is in the
> sort, what about allowing a backend to fork off dedicated sort
> processes? Aside from building multiple indexes at once, that
> functionality could also be useful in general queries.
Sure, that would be cool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Forgive me if I'm missing something obvious, but...
I am signed up to review, for example:
https://commitfest.postgresql.org/action/patch_view?id=107
If I click on the link for patch, I go to here:
http://archives.postgresql.org/message-id/162867790
--On Donnerstag, Mai 21, 2009 11:46:24 -0700 Steve Prentice
wrote:
Just for the record, you'd have to put the same kluge into the
T_RECORD
and T_ROW cases if we wanted to do it like this.
Patch updated.
Steve,
it seems there's something broken, patch complains about a broken format.
Can
Teodor, et al,
This is a review of the Polygons patch:
http://archives.postgresql.org/message-id/4a5761a2.8070...@sigaev.ru
There hasn't been any discussion, at least that I've been able to find.
Contents & Purpose
==
This small patch primarily fixes a couple polygon functions,
p
On Fri, 2009-07-17 at 12:50 -0500, Kevin Grittner wrote:
> Laurent Laborde wrote:
> (3) Allow override of the thresholds for individual columns.
>
> Are any of these non-controversial? What do people like there? What
> did I miss?
I would skip 1 and 2 and have (3).
Joshua D. Drake
--
Po
On Fri, Jul 17, 2009 at 8:58 AM, Fujii Masao wrote:
> Hi,
>
> On Fri, Jul 17, 2009 at 5:41 PM, Fujii Masao wrote:
>>> I'm reviewing this patch:
>>> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
>
> I updated the patch to solve two problems whi
Laurent Laborde wrote:
> What about trying to change the TOAST_TUPLE_TARGET to get a higher
> compression (by having more toasted record) ?
>
> I'd like to change the TOAST_TUPLES_PER_PAGE. Maybe from 4 to 8 ?
> Is that correct ? Did i missed something ?
>
> I did some statistics and i will h
On Fri, Jul 17, 2009 at 11:34 AM, Campbell, Lance wrote:
>
> I use postgres 8.1.X.
>
> Is there a way to add code completion when entering:
>
> set search_path = xyz
>
> I love the code completion for SQL. It would be really nice to have
> it for the "set search_path".
It sounds like a good idea
On Thu, 2009-07-16 at 21:31 -0700, Josh Berkus wrote:
> Robert,
>
> BTW, the new commitfest software is great. Easily a 75% reduction in
> time required to track reviewing activity.
I agree. It is much better. I have one suggestion. Make the headings
sortable (except maybe for patch name). That
I haven't paid much attention to the new commitfest app until now.
Generally, it looks good, but I'm wondering if we should have a
"committer" field.
I'm thinking of picking up at least the following items if/when they are
ready, but such a thing might help us to make sure we don't trip over
On Jul 15, 2009, at 2:52 PM, Dimitri Fontaine wrote:
Le 15 juil. 09 à 02:01, Glen Parker a écrit :
Sounds to me like another reason to separate index definition from
creation. If an index can be defined but not yet created or
valid, then you could imagine syntax like:
DEFINE INDEX blahblah
Stephen Frost wrote:
I agree that they should be consistant. The GRANT ON ALL shares alot
more of the syntax with GRANT than DefaultACL though, which makes it a
more interesting question there. I can understand not wanting to
duplicate the GRANT syntax. I think my suggestion would be to add a
Em Fri, 03 Apr 2009 04:23:10 -0300, Itagaki Takahiro
escreveu:
Vlad Arkhipov wrote:
Is it possible to print which key value is duplicated when 'Duplicate
key value violates unique constraint' occurs? Foreign key violation
error reports such kind of information.
I think it is not difficult
Pavel Stehule wrote:
> table was filled with random numbers and analyzed - you can simple
> check it - look on begin of the thread. This table wasn't updated.
Confirmed. The ORDER BY consistently speeds up the query. Odd
Sort speed varied based on random sequence generated, but typical
On Thu, Jul 16, 2009 at 10:41 AM, Peter Eisentraut wrote:
> On Thursday 16 July 2009 00:38:31 Fernando Ike de Oliveira wrote:
>> I applied the Tom Lane and Peter considerations, but I had that
>> remove one column (Owner) of out command \dL to compatibility with 7.4
>> version.
>
> The mandate is
I use postgres 8.1.X.
Is there a way to add code completion when entering:
set search_path = xyz
I love the code completion for SQL. It would be really nice to have
it for the "set search_path".
Thanks,
Lance Campbell
Project Manager/Software Architect/DBA
Web Services at Public Affairs
ALTER COLUMN SET DISTINCT
feels like adding a unique constraint.
ALTER COLUMN SET STATISTICS DISTINCT ?
ALTER COLUMN SET STATISTICS NDISTINCT ?
Greetings
Marcin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Hi,
Le 3 mai 09 à 22:13, Robert Haas a écrit :
OK, new version of patch, this time with the weird scaling removed and
the datatype changed to float4.
You've been assigning me this patch review, so here it goes :)
I have not changed the minimum value for remoteVersion in pg_dump.c,
as that wo
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
> A facility to show it in the logs (via log_line_prefix probably)
> would also be useful.
Agreed.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2009/7/17 Hitoshi Harada :
> 2009/7/17 Pavel Stehule :
>> Hello
>>
>> look on:
>> postgres=# explain select count(*) over () from x;
>> QUERY PLAN
>> -
>> WindowAgg (cost=0.00..265.00 rows=1 width=0)
>> ->
2009/7/17 Kevin Grittner :
> Pavel Stehule wrote:
>
>> postgres=# explain select count(*) over () from x;
>
>> WindowAgg (cost=0.00..265.00 rows=1 width=0)
>> -> Seq Scan on x (cost=0.00..140.00 rows=1 width=0)
>
>> postgres=# explain select count(*) over (order by a) from x;
>
>>
Pavel Stehule wrote:
> postgres=# explain select count(*) over () from x;
> WindowAgg (cost=0.00..265.00 rows=1 width=0)
>-> Seq Scan on x (cost=0.00..140.00 rows=1 width=0)
> postgres=# explain select count(*) over (order by a) from x;
> WindowAgg (cost=0.00..556.25 rows
Hi,
On Fri, Jul 17, 2009 at 5:41 PM, Fujii Masao wrote:
>> I'm reviewing this patch:
>> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
I updated the patch to solve two problems which you pointed.
Here is the changes:
* Prevented the obsolet
Michael Meskes írta:
> On Fri, Jul 17, 2009 at 12:27:49PM +0200, Boszormenyi Zoltan wrote:
>
>> one of our clients wants to port their application suite
>> from Informix to PostgreSQL, they use constructs like
>>
>> SELECT * INTO :tablerec FROM table ...
>>
>> where "tablerec" mirrors the table
One more typo fix in docs
--
Regards
Petr Jelinek (PJMODOS)
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index bf963b8..6400f9e 100644
*** a/doc/src/sgml/ref/grant.sgml
--- b/doc/src/sgml/ref/grant.sgml
*** PostgreSQL documentation
*** 23,39
GRANT
Hey,
* Nikhil Sontakke (nikhil.sonta...@enterprisedb.com) wrote:
> > We can certainly do it either way, but I don't see much downside to
> > having a new enum and a number of downsides with modifying the existing
> > grant enums.
>
> Sure, I understand. But if we want to go the DefaultACLs way, t
Hi,
>> I briefly looked at the DefaultACLs patch. Can you not re-use the
>> GrantStmt structure for the defaults purpose too? You might have to
>> introduce an "is_default" boolean similar to the "is_schema" boolean
>> that you have added in the "GRANT ON ALL" patch. If you think you can
>> re-us
On Friday 17 July 2009 06:10:12 Robert Haas wrote:
> 2009/7/16 KaiGai Kohei :
> > Yes, the tiny version will not give any advantages in security without
> > future enhancements.
> > It is not difficult to add object classes and permissions.
> > If necessary, I'll add checks them with corresponding
Nikhil,
* Nikhil Sontakke (nikhil.sonta...@enterprisedb.com) wrote:
> I briefly looked at the DefaultACLs patch. Can you not re-use the
> GrantStmt structure for the defaults purpose too? You might have to
> introduce an "is_default" boolean similar to the "is_schema" boolean
> that you have adde
On Fri, Jul 17, 2009 at 12:27:49PM +0200, Boszormenyi Zoltan wrote:
> one of our clients wants to port their application suite
> from Informix to PostgreSQL, they use constructs like
>
> SELECT * INTO :tablerec FROM table ...
>
> where "tablerec" mirrors the table fields in a C struct.
Well, thi
Nikhil Sontakke wrote:
There is however one thing that needs some attention. Both patches add
distinction between VIEW and TABLE objects for acls into parser and they
both do it differently. GRANT ON ALL works by adding ACL_OBJECT_VIEW and
tracks that object type in code (that was my original met
Hi,
one of our clients wants to port their application suite
from Informix to PostgreSQL, they use constructs like
SELECT * INTO :tablerec FROM table ...
where "tablerec" mirrors the table fields in a C struct.
Currently ECPG dumps core on this, more exactly aborts on it
in ecpg_type_name().
P
Nikhil Sontakke wrote:
grant.sgml
* Maybe we should use
schemaname in the sgml
references instead of just schemaname
+There is also the posibility of granting permissions to all objects of
+given type inside one or multiple schemas. This functionality is supported
+for tables, views
Hi,
>
> Attached is v2 with slightly improved code, nothing has changed
> feature-wise.
>
Here are some comments on this patch from my side:
grant.sgml
* Maybe we should use
schemaname in the sgml
references instead of just schemaname
+There is also the posibility of granting permissions t
Hi,
On Fri, Jul 17, 2009 at 2:09 AM, Greg Stark wrote:
> Only the sysadmin is actually going to know which makes more sense.
> Unless we start tieing WAL parameters to the database size or
> something like that.
Agreed. And, if a user doesn't want to make a new base backup because
of a large data
Hi,
On Thu, Jul 16, 2009 at 6:00 PM, Heikki
Linnakangas wrote:
> The archive should not normally contain partial XLOG files, only if you
> manually copy one there after primary has crashed. So I don't think
> that's something we need to support.
You are right. And, if the last valid record exists
Hi,
>>
>
> No, DefaultACLs applies to objects created in the future while GRANT ON ALL
> affects existing objects.
I see.
> DefaultACLs is more important functionality so it should probably take
> precedence in review process.
>
> There is however one thing that needs some attention. Both patche
Hi Jaime,
On Fri, Jul 17, 2009 at 6:31 AM, Jaime
Casanova wrote:
> I'm reviewing this patch:
> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
Thanks for reviewing the patch!
> something that make me nervous is this:
>/*
> * N
Jaime Casanova wrote:
i did it myself, i think this is something we need...
this compile and seems to work... something i was wondering is that
having the total time of lock waits is not very accurate because we
can have 9 lock waits awaiting 1 sec each and one awaiting for 1
minute... simply s
On Thursday 16 July 2009 22:08:25 Kevin Grittner wrote:
> On the admin list there was a request for an application name
> column in pg_stat_activity.
>
> http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php
>
> This is available in a lot of other DBMS products, can be useful to
> DBAs, a
Friendly greetings !
I'd like to have a higher compression ratio on our base.
>From pg 8.3 documentation :
The TOAST code is triggered only when a row value to be stored in a
table is wider than TOAST_TUPLE_THRESHOLD bytes (normally 2 kB).
The TOAST code will compress and/or move field values out
On Wednesday 08 July 2009 02:09:20 Alvaro Herrera wrote:
> It seems our makefiles fail to install fmgroids.h by "make install" in a
> VPATH build.
> I think the solution is to treat fmgroids.h just like pg_config_os.h,
> i.e. add a line like this:
>
> $(INSTALL_DATA) utils/fmgroids.h '$(DEST
On Thursday 16 July 2009 23:50:14 Greg Smith wrote:
> On Thu, 16 Jul 2009, Josh Berkus wrote:
> > Well, after an hour of tinkering with docbook DTDs and openjade I've
> > given up on building docs for the patch I was reviewing on my Mac.
>
> It's easier to get the whole chain working under Linux, b
On Tuesday 07 July 2009 23:31:54 Marko Tiikkaja wrote:
> Here's a patch(WIP) that implements INSERT .. RETURNING inside a CTE.
Could you supply some test cases to illustrate what this patch accomplishes?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
2009/7/17 Pavel Stehule :
> Hello
>
> look on:
> postgres=# explain select count(*) over () from x;
> QUERY PLAN
> -
> WindowAgg (cost=0.00..265.00 rows=1 width=0)
> -> Seq Scan on x (cost=0.00..140.00 row
84 matches
Mail list logo
