Itagaki Takahiro wrote:
> I'm working on alternative version of VACUUM FULL, which is
> like CLUSTER but sort tuples in ctid order without index.
> The original discussion is here:
> [HACKERS] Feedback on getting rid of VACUUM FULL
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg0
I am starting to plan a few features that are important for temporal
data, and one prerequisite for several of them is the ability to find an
operator that fills a certain role.
For instance, one feature that I'm considering now is a "temporal join"
which is a join on "overlaps" rather than "equal
On tor, 2009-10-22 at 10:59 -0300, Alvaro Herrera wrote:
> What I am wondering right now is whether we could have two separate
> attributes, one SUSET defining what goes to the log, and another one
> USERSET defining what's sent to the client.
Note that only glibc supports switching the language a
On Thu, Oct 22, 2009 at 11:00 PM, João Eugenio Marynowski
wrote:
> I don't be able to select the data from table with pg_dump or select, both
> occur error...
> how i can identified the register of a table independent the contends of the
> register, only control of the postgres?
> I eliminate the
I'm working on alternative version of VACUUM FULL, which is
like CLUSTER but sort tuples in ctid order without index.
The original discussion is here:
[HACKERS] Feedback on getting rid of VACUUM FULL
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01047.php
WIP patch attached. I ha
I don't be able to select the data from table with pg_dump or select, both
occur error...
how i can identified the register of a table independent the contends of the
register, only control of the postgres?
I eliminate the index pk but now I don't be able to create begin because
show the error:
ERR
On Thu, Oct 22, 2009 at 10:34 PM, João Eugenio Marynowski
wrote:
> The hardware is ok because we have migrated to other machine and the errors
> is the same
> zero_damaged_pages is on and the vaccum verbose don't show any error...
You need to dump (or otherwise extract) your data and load it into
The hardware is ok because we have migrated to other machine and the errors
is the same
zero_damaged_pages is on and the vaccum verbose don't show any error...
2009/10/22 Joshua D. Drake
> On Thu, 2009-10-22 at 14:28 -0200, João Eugenio Marynowski wrote:
> > Hi
> >
> Repair? Not likely. Get past
Greg Stark escribió:
> There is another use case which perhaps needs to be addressed: if the
> user has some queries which are very latency sensitive and others
> which are not latency sensitive. In that case it might be very
> important to keep the pages of data used by the high priority queries
Magnus Hagander wrote:
> 2009/10/22 Alvaro Herrera :
> > What I am wondering right now is whether we could have two separate
> > attributes, one SUSET defining what goes to the log, and another one
> > USERSET defining what's sent to the client.
> This would allow me to have the client messages i
2009/10/22 Alvaro Herrera :
> So right now we have a single GUC determining the language that log
> messages are in, and it is PGC_SUSET to avoid a user from sending
> messages to the log that the DBA cannot read.
>
> However, this means that the client cannot get the messages in the
> language of
On Thu, 2009-10-22 at 14:28 -0200, João Eugenio Marynowski wrote:
> Hi
>
Repair? Not likely. Get past? Maybe.
set zero_damaged_pages to on;
vacuum verbose;
I would do a hardware check too.
Joshua D. Drake
> Can someone help me how to repair the problem below, I'm using
> Postgres 8.2.5:
> - a
Hi
Can someone help me how to repair the problem below, I'm using Postgres
8.2.5:
- after appeared the erros below in selects, vacuum and dump in one table:
2009-10-16 16:07:06 BRT 192.168.0.87 ERROR: could not access status of
transaction 29024764
2009-10-16 16:07:06 BRT 192.168.0.87 DETAIL: Co
Dimitri Fontaine writes:
> But it will set GET DIAGNOSTIC ... = ROW_COUNT, am I being told on IRC.
This has been discussed before, please read archives.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Thu, 2009-10-22 at 11:33 -0400, Robert Haas wrote:
> On Thu, Oct 22, 2009 at 11:16 AM, Cédric Villemain
> wrote:
> > Le lundi 19 octobre 2009 23:27:20, Greg Stark a écrit :
> >> On Mon, Oct 19, 2009 at 2:08 PM, marcin mank wrote:
> >> > Currently random_page_cost is a GUC. I propose that this
Hi,
Attached is a WIP patch which implements writeable CTEs. This patch has
some defects I'll be discussing below. Also, I haven't implemented the
grammar changes for using WITH ( .. RETURNING ) in non-SELECT queries
yet.
What's not obvious from the patch:
- estate->es_result_relation_in
But it will set GET DIAGNOSTIC ... = ROW_COUNT, am I being told on IRC.
I was really suprised FOUND is not set by EXECUTE in 8.3 when doing a
partitioning UPDATE trigger (we partition a summary table and have to
see about doing UPSERT).
As I wouldn't have figured GET DIAGNOSTIC was the way to go
Well I think we need sone way to accomplish the same high level goal
of guaranteeing response times for latency-critical queries.
However my point is that cache policy is an internal implementation
detail we don't want to expose in a user interface.
--
Greg
On 2009-10-22, at 11:41 AM, "Kev
Andrew Dunstan writes:
> I don't see why it feels any more foreign than, say, #pragma in C.
>
> And it's something we already have, albeit undocumented.
>
> Let's not get too hung up on syntax.
Ok just wanted to have this syntax part explicitely talked about, I
don't have strong opinions about it
On Thu, Oct 22, 2009 at 2:28 PM, Josh Berkus wrote:
> All,
>
> Wouldn't per *tablespace* costs make more sense?
>
> --Josh
Yes, we already had several votes in favor of that approach. See upthread.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Greg Stark wrote:
> There is another use case which perhaps needs to be addressed: if
> the user has some queries which are very latency sensitive and
> others which are not latency sensitive.
Yes. Some products allow you to create a named cache and bind
particular objects to it. This can be
All,
Wouldn't per *tablespace* costs make more sense?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[moving to pgsql-hackers]
On Thu, Oct 22, 2009 at 10:28 AM, David Jantzen wrote:
> Thanks for the quick response Joshua, much appreciated. Is there any
> way to avoid or minimize a period without a warm standby when I switch
> to Server B for production? What about rsyncing the data directory
>
I wrote:
> [ EvalPlanQual does not work well ]
I'm planning to go back to work on this now that we're out of
CommitFest.
> We could improve that by feeding successfully locked rows into the EPQ
> machinery as well as ones that were found to be outdated. But that
> would still leave us with two f
On Thu, Oct 22, 2009 at 8:16 AM, Cédric Villemain
wrote:
> You can have situation where you don't want some tables go to OS memory
I don't think this is a configuration we want to cater for. The
sysadmin shouldn't be required to understand the i/o pattern of
postgres. He or she cannot know whethe
On Wed, 2009-10-21 at 23:55 -0700, edwardyf wrote:
> If the index is on an attribute with duplicate values. will it be:
> 1) one index tuple for each row, though with the same value, or
> 2) one index tuple for each value, containing a list of row ids.
As Tom already pointed out, #1 is the answer.
Just to intoduce myself, I'm Marc Munro the developer of Veil, a
postgres add-in that allows you to implement virtual private databases
using views.
The problem we are discussing here is the existence of covert or
side-channels being available from functions that can leak information
about the row
Hi everybody,
Can someone help me how to repair the problem below, I'm using Postgres
8.2.5:
- after appeared the erros below in selects, vacuum and dump in one table:
2009-10-16 16:07:06 BRT 192.168.0.87 ERROR: could not access status of
transaction 29024764
2009-10-16 16:07:06 BRT 192.168.0.87 D
2009/10/22 Tom Lane :
> Pavel Stehule writes:
>> 2009/10/22 Tom Lane :
>>> It is not --- it's the recommended solution for emulating computed
>>> columns. The column-as-f(x) direction maybe isn't terribly exciting,
>>> but the function-as-x.col direction definitely is.
>
>> is it documented?
>
>
Pavel Stehule writes:
> 2009/10/22 Tom Lane :
>> It is not --- it's the recommended solution for emulating computed
>> columns. Â The column-as-f(x) direction maybe isn't terribly exciting,
>> but the function-as-x.col direction definitely is.
> is it documented?
Yes, see "SQL Functions on Compo
On Thu, Oct 22, 2009 at 11:16 AM, Cédric Villemain
wrote:
> Le lundi 19 octobre 2009 23:27:20, Greg Stark a écrit :
>> On Mon, Oct 19, 2009 at 2:08 PM, marcin mank wrote:
>> > Currently random_page_cost is a GUC. I propose that this could be set
>> > per-table.
>>
>> Or per-tablespace.
>>
>> Yes,
2009/10/22 Tom Lane :
> Pavel Stehule writes:
>> 2009/10/22 Tom Lane :
>>> Pavel Stehule writes:
this is syntax column(table) necessary still?
>
>>> There is no reason to remove that.
>
>> do you know somebody who use it? It is dead code.
>
> It is not --- it's the recommended solution for e
Le lundi 19 octobre 2009 23:27:20, Greg Stark a écrit :
> On Mon, Oct 19, 2009 at 2:08 PM, marcin mank wrote:
> > Currently random_page_cost is a GUC. I propose that this could be set
> > per-table.
>
> Or per-tablespace.
>
> Yes, I think there are a class of GUCs which describe the physical
> a
edwardyf writes:
> If the index is on an attribute with duplicate values. will it be:
> 1) one index tuple for each row, though with the same value, or
> 2) one index tuple for each value, containing a list of row ids.
1.
regards, tom lane
--
Sent via pgsql-hackers mail
Le lundi 19 octobre 2009 23:14:40, Robert Haas a écrit :
> On Mon, Oct 19, 2009 at 5:08 PM, marcin mank wrote:
> > Currently random_page_cost is a GUC. I propose that this could be set
> > per-table.
> >
> > I think this is a good idea for widely-wanted planner hints. This way
> > You can say "I d
On Thu, Oct 22, 2009 at 10:22 AM, Pavel Stehule wrote:
> 2009/10/22 Tom Lane :
>> Pavel Stehule writes:
>>> this is syntax column(table) necessary still?
>>
>> There is no reason to remove that.
>>
>
> do you know somebody who use it? It is dead code. Processing of call
> functions should be simp
Le mardi 20 octobre 2009 06:30:26, Greg Smith a écrit :
> On Mon, 19 Oct 2009, Jeff Davis wrote:
> > On Mon, 2009-10-19 at 21:22 -0500, Kevin Grittner wrote:
> >> I'd bet accounts receivable applications often hit that.
> >> (Most payments on recent billings; a sprinkling on older ones.)
> >> I'm s
Pavel Stehule writes:
> 2009/10/22 Tom Lane :
>> Pavel Stehule writes:
>>> this is syntax column(table) necessary still?
>> There is no reason to remove that.
> do you know somebody who use it? It is dead code.
It is not --- it's the recommended solution for emulating computed
columns. The co
2009/10/22 Tom Lane :
> Pavel Stehule writes:
>> this is syntax column(table) necessary still?
>
> There is no reason to remove that.
>
do you know somebody who use it? It is dead code. Processing of call
functions should be simpler.
Pavel
> regards, tom lane
>
--
Sent
On Thu, Oct 22, 2009 at 10:12 AM, Andrew Dunstan wrote:
> Let's not get too hung up on syntax.
+1.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dimitri Fontaine wrote:
I know I don't like #option because it looks and feels "foreign", so t
might just boils down to syntax issue for others too.
I don't see why it feels any more foreign than, say, #pragma in C.
And it's something we already have, albeit undocumented.
Let's not get
Pavel Stehule writes:
> this is syntax column(table) necessary still?
There is no reason to remove that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
So right now we have a single GUC determining the language that log
messages are in, and it is PGC_SUSET to avoid a user from sending
messages to the log that the DBA cannot read.
However, this means that the client cannot get the messages in the
language of his choice.
What I am wondering right
If the index is on an attribute with duplicate values. will it be:
1) one index tuple for each row, though with the same value, or
2) one index tuple for each value, containing a list of row ids.
thanx
--
View this message in context:
http://www.nabble.com/B-tree-leaf-node-structure-tp26004939p
>
> \c - secretary
>
> CREATE OR REPLACE FUNCTION expose_person (person text, phone text)
> RETURNS bool AS $$
> begin
> RAISE NOTICE 'person: % number: %', person, phone;
> RETURN true;
> END; $$ LANGUAGE plpgsql COST 0.01;
>
> postgres=> SELECT * FROM phone_number WHERE expose_person(perso
Updated patch attached. Per discussion, this:
- Changes the envvar name to PGAPPNAME
- Removes support for setting application_name in the startup packet,
and instead sends an explicit SET command as part of the connection
setup in PQconnectPoll. In order to avoid adding to the
application-visible
On Thu, Oct 22, 2009 at 6:03 AM, Heikki Linnakangas
wrote:
> In chapter "36.4 Rules and Privileges" we show an example of using a
> view to expose part of a table to other users, keeping other rows private:
>
>> For example: A user has a list of phone numbers where some of them are
> private, the
Pavel Stehule wrote:
>
> postgres=# create or replace function vv(int, int) returns bool as
> $$begin raise notice '% %', $1, $2; return true; end$$ language
> plpgsql COST 0.01;
> CREATE FUNCTION
> postgres=# select * from v where vv(a,b);NOTICE: 10 20
> a │ b
> ───┼───
> (0 rows)
>
> stil
2009/10/22 Richard Huxton :
> Pavel Stehule wrote:
>> 2009/10/22 Heikki Linnakangas :
>>> That example I ran on CVS HEAD, but it's a generic problem on all versions.
>> postgres=# select version();
>> version
>>
Richard Huxton wrote:
> Heikki Linnakangas wrote:
>> CREATE VIEW phone_number AS
>> SELECT person, phone FROM phone_data WHERE phone NOT LIKE '6%';
>
>> CREATE OR REPLACE FUNCTION expose_person (person text, phone text)
>> RETURNS bool AS $$
>> begin
>> RAISE NOTICE 'person: % number: %', pe
Pavel Stehule wrote:
> 2009/10/22 Heikki Linnakangas :
>> That example I ran on CVS HEAD, but it's a generic problem on all versions.
> postgres=# select version();
>version
> ───
2009/10/22 Heikki Linnakangas :
> That example I ran on CVS HEAD, but it's a generic problem on all versions.
postgres=# select version();
version
PostgreSQL 8.5d
Pavel Stehule wrote:
> What version do you have?
>
> I am cannot repeat it.
It will depend on the relative cost of the clauses (though 0.0001 should
have been enough to force it). Try:
CREATE OR REPLACE FUNCTION row_hidden (phone text) RETURNS bool AS $$
BEGIN
RETURN phone LIKE '6%';
END;
$$
That example I ran on CVS HEAD, but it's a generic problem on all versions.
Pavel Stehule wrote:
> What version do you have?
>
> I am cannot repeat it.
>
> Regards
> Pavel Stehule
>
> 2009/10/22 Richard Huxton :
>> Heikki Linnakangas wrote:
>>> CREATE VIEW phone_number AS
>>> SELECT person,
What version do you have?
I am cannot repeat it.
Regards
Pavel Stehule
2009/10/22 Richard Huxton :
> Heikki Linnakangas wrote:
>> CREATE VIEW phone_number AS
>> SELECT person, phone FROM phone_data WHERE phone NOT LIKE '6%';
>
>> CREATE OR REPLACE FUNCTION expose_person (person text, phone t
Heikki Linnakangas wrote:
> CREATE VIEW phone_number AS
> SELECT person, phone FROM phone_data WHERE phone NOT LIKE '6%';
> CREATE OR REPLACE FUNCTION expose_person (person text, phone text)
> RETURNS bool AS $$
> begin
> RAISE NOTICE 'person: % number: %', person, phone;
> RETURN true;
>
2009/10/22 Dimitri Fontaine :
> Tom Lane writes:
>> be seen as one.) And the Oracle-compatible option will be attractive
>> to people coming in from that side. Reviewing megabytes of pl/sql
>> code for this kind of gotcha is not fun, and the "error" default would
>> only help a bit.
>
> What abo
Tom Lane writes:
> be seen as one.) And the Oracle-compatible option will be attractive
> to people coming in from that side. Reviewing megabytes of pl/sql
> code for this kind of gotcha is not fun, and the "error" default would
> only help a bit.
What about having a new pl language called plsq
In chapter "36.4 Rules and Privileges" we show an example of using a
view to expose part of a table to other users, keeping other rows private:
> For example: A user has a list of phone numbers where some of them are
private, the others are of interest for the secretary of the office. He
can const
On Thu, 2009-10-22 at 09:41 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-10-22 at 07:55 +0300, Heikki Linnakangas wrote:
> >> Making some effort to transfer locks instead of acquiring+releasing
> >> would eliminate the need for having extra lock space available when
> >> s
60 matches
Mail list logo
