KSQO parameter

Started by Bruce Momjianover 24 years ago17 messages

pgman@candle.pha.pa.us

over 24 years ago

Is there any value to KQSO parameter? It was for complex OR clauses. I
thought Tom fixed most of that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tom Lane

tgl@sss.pgh.pa.us

over 24 years ago

In reply to: Bruce Momjian (#1)

Re: KSQO parameter

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there any value to KQSO parameter? It was for complex OR clauses. I
thought Tom fixed most of that.

The last set of tests that I did (~7.0) showed that it was still
marginally faster than the default approach. Not a "must have"
like it used to be for those queries, though.

As of 7.1 it is disabled anyway, because I didn't have time to update
the KSQO code for the new implementation of UNION and friends.

We should either update the code or remove it entirely. I still don't
have the time or interest to do #1, but I'm not quite ready to do #2
either ... does anyone out there want to work on it?

regards, tom lane

Bruce Momjian

pgman@candle.pha.pa.us

over 23 years ago

In reply to: Tom Lane (#2)

1 attachment(s)

Re: [HACKERS] KSQO parameter

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there any value to KQSO parameter? It was for complex OR clauses. I
thought Tom fixed most of that.

The last set of tests that I did (~7.0) showed that it was still
marginally faster than the default approach. Not a "must have"
like it used to be for those queries, though.

As of 7.1 it is disabled anyway, because I didn't have time to update
the KSQO code for the new implementation of UNION and friends.

We should either update the code or remove it entirely. I still don't
have the time or interest to do #1, but I'm not quite ready to do #2
either ... does anyone out there want to work on it?

The following patch removes KSQO from GUC and the call to the function.
It also moves the main KSQO file into _deadcode. Applied.

ODBC folks, should I remove KSQO from the ODBC driver?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Attachments:

/bjm/difftext/plainDownload

Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.118
diff -c -r1.118 runtime.sgml
*** doc/src/sgml/runtime.sgml	15 Jun 2002 19:58:53 -0000	1.118
--- doc/src/sgml/runtime.sgml	15 Jun 2002 23:27:27 -0000
***************
*** 760,793 ****
       </varlistentry>
  
       <varlistentry>
-       <term><varname>KSQO</varname> (<type>boolean</type>)</term>
-       <listitem>
-        <para>
-         The <firstterm>Key Set Query Optimizer</firstterm>
-         (<acronym>KSQO</acronym>) causes the query planner to convert
-         queries whose <literal>WHERE</> clause contains many OR'ed AND
-         clauses (such as <literal>WHERE (a=1 AND b=2) OR (a=2 AND b=3)
-         ...</literal>) into a union query. This method can be faster
-         than the default implementation, but it doesn't necessarily give
-         exactly the same results, since <literal>UNION</> implicitly
-         adds a <literal>SELECT DISTINCT</> clause to eliminate identical
-         output rows. <acronym>KSQO</acronym> is commonly used when
-         working with products like <productname>Microsoft
-         Access</productname>, which tend to generate queries of this
-         form.
-        </para>
- 
-        <para>
-         The <acronym>KSQO</acronym> algorithm used to be absolutely
-         essential for queries with many OR'ed AND clauses, but in
-         <productname>PostgreSQL</productname> 7.0 and later the standard
-         planner handles these queries fairly successfully; hence the
-         default is off.
-        </para>
-       </listitem>
-      </varlistentry>
- 
-      <varlistentry>
        <term><varname>RANDOM_PAGE_COST</varname> (<type>floating point</type>)</term>
        <listitem>
         <para>
--- 760,765 ----
Index: src/backend/optimizer/plan/planner.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v
retrieving revision 1.120
diff -c -r1.120 planner.c
*** src/backend/optimizer/plan/planner.c	13 Jun 2002 15:10:25 -0000	1.120
--- src/backend/optimizer/plan/planner.c	15 Jun 2002 23:27:29 -0000
***************
*** 145,155 ****
  	PlannerQueryLevel++;
  	PlannerInitPlan = NIL;
  
- #ifdef ENABLE_KEY_SET_QUERY
- 	/* this should go away sometime soon */
- 	transformKeySetQuery(parse);
- #endif
- 
  	/*
  	 * Check to see if any subqueries in the rangetable can be merged into
  	 * this query.
--- 145,150 ----
Index: src/backend/optimizer/prep/Makefile
===================================================================
RCS file: /cvsroot/pgsql/src/backend/optimizer/prep/Makefile,v
retrieving revision 1.12
diff -c -r1.12 Makefile
*** src/backend/optimizer/prep/Makefile	31 Aug 2000 16:10:13 -0000	1.12
--- src/backend/optimizer/prep/Makefile	15 Jun 2002 23:27:29 -0000
***************
*** 12,18 ****
  top_builddir = ../../../..
  include $(top_builddir)/src/Makefile.global
  
! OBJS = prepqual.o preptlist.o prepunion.o prepkeyset.o
  
  all: SUBSYS.o
  
--- 12,18 ----
  top_builddir = ../../../..
  include $(top_builddir)/src/Makefile.global
  
! OBJS = prepqual.o preptlist.o prepunion.o
  
  all: SUBSYS.o
  
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.69
diff -c -r1.69 guc.c
*** src/backend/utils/misc/guc.c	17 May 2002 20:32:29 -0000	1.69
--- src/backend/utils/misc/guc.c	15 Jun 2002 23:27:32 -0000
***************
*** 312,322 ****
  		{ "enable_hashjoin", PGC_USERSET }, &enable_hashjoin,
  		true, NULL, NULL
  	},
- 
- 	{
- 		{ "ksqo", PGC_USERSET }, &_use_keyset_query_optimizer,
- 		false, NULL, NULL
- 	},
  	{
  		{ "geqo", PGC_USERSET }, &enable_geqo,
  		true, NULL, NULL
--- 312,317 ----
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.39
diff -c -r1.39 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample	15 Jun 2002 01:29:50 -0000	1.39
--- src/backend/utils/misc/postgresql.conf.sample	15 Jun 2002 23:27:32 -0000
***************
*** 89,96 ****
  #enable_mergejoin = true
  #enable_hashjoin = true
  
- #ksqo = false
- 
  #effective_cache_size = 1000	# default in 8k pages
  #random_page_cost = 4
  #cpu_tuple_cost = 0.01
--- 89,94 ----
Index: src/bin/psql/tab-complete.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/tab-complete.c,v
retrieving revision 1.49
diff -c -r1.49 tab-complete.c
*** src/bin/psql/tab-complete.c	15 Jun 2002 19:43:47 -0000	1.49
--- src/bin/psql/tab-complete.c	15 Jun 2002 23:27:34 -0000
***************
*** 226,232 ****
  		"enable_nestloop",
  		"enable_mergejoin",
  		"enable_hashjoin",
- 		"ksqo",
  		"geqo",
  		"fsync",
  		"server_min_messages",
--- 226,231 ----
***************
*** 695,701 ****
  
  			COMPLETE_WITH_LIST(my_list);
  		}
! 		else if (strcasecmp(prev2_wd, "GEQO") == 0 || strcasecmp(prev2_wd, "KSQO") == 0)
  		{
  			char	   *my_list[] = {"ON", "OFF", "DEFAULT", NULL};
  
--- 694,700 ----
  
  			COMPLETE_WITH_LIST(my_list);
  		}
! 		else if (strcasecmp(prev2_wd, "GEQO") == 0)
  		{
  			char	   *my_list[] = {"ON", "OFF", "DEFAULT", NULL};
  
Index: src/include/optimizer/planmain.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/optimizer/planmain.h,v
retrieving revision 1.57
diff -c -r1.57 planmain.h
*** src/include/optimizer/planmain.h	18 May 2002 02:25:50 -0000	1.57
--- src/include/optimizer/planmain.h	15 Jun 2002 23:27:34 -0000
***************
*** 62,72 ****
  							 Index acceptable_rel);
  extern void fix_opids(Node *node);
  
- /*
-  * prep/prepkeyset.c
-  */
- extern bool _use_keyset_query_optimizer;
- 
- extern void transformKeySetQuery(Query *origNode);
- 
  #endif   /* PLANMAIN_H */
--- 62,65 ----

Dave Page

dpage@vale-housing.co.uk

over 23 years ago

In reply to: Bruce Momjian (#3)

Re: [HACKERS] KSQO parameter

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: 16 June 2002 01:09
To: Tom Lane
Cc: PostgreSQL-development; PostgreSQL odbc list
Subject: Re: [ODBC] [HACKERS] KSQO parameter

either ... does anyone out there want to work on it?

The following patch removes KSQO from GUC and the call to the
function. It also moves the main KSQO file into _deadcode. Applied.

ODBC folks, should I remove KSQO from the ODBC driver?

I'm not sure that Hiroshi has updated CVS with all our recent changes
just yet - there is certainly a patch outstanding that redesigns the
setup dialogues that I posted that would be affected by this...

Regards, Dave.

Import Notes

Resolved by subject fallback

Hiroshi Inoue

Inoue@tpf.co.jp

over 23 years ago

In reply to: Dave Page (#4)

Re: [HACKERS] KSQO parameter

Dave Page wrote:

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: 16 June 2002 01:09
To: Tom Lane
Cc: PostgreSQL-development; PostgreSQL odbc list
Subject: Re: [ODBC] [HACKERS] KSQO parameter

either ... does anyone out there want to work on it?

The following patch removes KSQO from GUC and the call to the
function. It also moves the main KSQO file into _deadcode. Applied.

ODBC folks, should I remove KSQO from the ODBC driver?

I'm not sure that Hiroshi has updated CVS with all our recent changes
just yet

Sorry I've had no time to see it.

- there is certainly a patch outstanding that redesigns the
setup dialogues that I posted that would be affected by this...

I don't object to remove the KSQO option at server side.
But why must the option be removed from the odbc driver
together ? As I mentioned many many times, the driver
isn't only for the recent (especially not yet released)
version of servers. I think we had better have a separate
dialog for obsolete options.

regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/

Bruce Momjian

pgman@candle.pha.pa.us

over 23 years ago

In reply to: Hiroshi Inoue (#5)

Re: [HACKERS] KSQO parameter

Hiroshi Inoue wrote:

- there is certainly a patch outstanding that redesigns the
setup dialogues that I posted that would be affected by this...

I don't object to remove the KSQO option at server side.
But why must the option be removed from the odbc driver
together ? As I mentioned many many times, the driver
isn't only for the recent (especially not yet released)
version of servers. I think we had better have a separate
dialog for obsolete options.

Yes, this is why I am asking. If you want to keep it for <7.1 releases,
that is fine.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Marek Mosiewicz

marekmosiewicz@poczta.onet.pl

over 23 years ago

In reply to: Dave Page (#4)

Native OLE DB. What do you think about it

Hello everbody.

I have started work on native OLE DB Provider for PostgreSQL. i think it is
really important to have native OLE DB proviader even if there is OLE DB to
ODBC Provider. Microsoft started to withdraw support for ODBC and seems to
force to switch to OLE DB(eg VS .Net have limited support for ODBC which
must be spearetly downloaded), so we could expect more such moves. So I
started work on native PostgreSQL OLE DB provider. It slowly begin
to work. (it registers to system, shows property pages, connects to
database, and do first quries). Now I'm working on creating resultset.

I would like somebody to help answer some questions:

1.is it safe to use binary cursors (basic types format e.g date would not
change in future)
2.how could I control result type (binary/ASCII) for ordinary SELECTS ?
3.could ODBC driver mix auto-commit and FETCH/DECLARE mode ? how it can
handle such situation:
start select (fetch some data) /as I understand it should start
transaction silently/
update (it should commit as we are in auto-commit)
fetch more data.
next update (commit again)
4. maybe it would have sense to make some common library with ODBC to handle
prepared statements and some kind of conversions (althougth maybe not
becouse we convert to different types (OLE DB uses OLE Automation types))
5. Is there any way to truncate PQresult in libpq ? I implement fast forward
cursors so i have no need to store whole result (I can read piece of data
and forget it when client read it from me). I think there would be no
problem if I add some PQtruncate(PQresult *) to pqlib, but maybe there is
any different way ?

I use ATL templates for OLE DB which is MS library and it can't be compiled
withot Visual Studio. (you have right to distribute ATL if you bougth VS).
So It would be not "pure" solution, but starting from scratch is to
difficult, as I don't know COM prefectly. Maybe somebody will rewrite it
later.

Christopher Kings-Lynne

chriskl@familyhealth.com.au

over 23 years ago

In reply to: Marek Mosiewicz (#7)

Re: [HACKERS] Native OLE DB. What do you think about it

Are you aware that another team on the list is working on a .Net provider?
Maybe you could work with them?

.Net Provider people: speak up!

Chris

Show quoted text

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Marek Mosiewicz
Sent: Monday, 17 June 2002 4:34 PM
To: PostgreSQL-development; PostgreSQL odbc list
Subject: [HACKERS] Native OLE DB. What do you think about it

Hello everbody.

I have started work on native OLE DB Provider for PostgreSQL. i
think it is
really important to have native OLE DB proviader even if there is
OLE DB to
ODBC Provider. Microsoft started to withdraw support for ODBC and seems to
force to switch to OLE DB(eg VS .Net have limited support for ODBC which
must be spearetly downloaded), so we could expect more such moves. So I
started work on native PostgreSQL OLE DB provider. It slowly begin
to work. (it registers to system, shows property pages, connects to
database, and do first quries). Now I'm working on creating resultset.

I would like somebody to help answer some questions:

1.is it safe to use binary cursors (basic types format e.g date would not
change in future)
2.how could I control result type (binary/ASCII) for ordinary SELECTS ?
3.could ODBC driver mix auto-commit and FETCH/DECLARE mode ? how it can
handle such situation:
start select (fetch some data) /as I understand it should start
transaction silently/
update (it should commit as we are in auto-commit)
fetch more data.
next update (commit again)
4. maybe it would have sense to make some common library with
ODBC to handle
prepared statements and some kind of conversions (althougth maybe not
becouse we convert to different types (OLE DB uses OLE Automation types))
5. Is there any way to truncate PQresult in libpq ? I implement
fast forward
cursors so i have no need to store whole result (I can read piece of data
and forget it when client read it from me). I think there would be no
problem if I add some PQtruncate(PQresult *) to pqlib, but maybe there is
any different way ?

I use ATL templates for OLE DB which is MS library and it can't
be compiled
withot Visual Studio. (you have right to distribute ATL if you bougth VS).
So It would be not "pure" solution, but starting from scratch is to
difficult, as I don't know COM prefectly. Maybe somebody will rewrite it
later.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Dave Page

dpage@vale-housing.co.uk

over 23 years ago

In reply to: Christopher Kings-Lynne (#8)

Re: [HACKERS] Native OLE DB. What do you think about it

Ahh, that would be us then :-) Yes, there is a (very) active .NET
provider project underway - it can be found at
http://gborg.postgresql.org/project/npgsql. Note though, that this is a
native .NET provider being written in C#, it is not OLE-DB (which would
certainly be a useful addition to the list of interfaces imho).

Regards, Dave.

Show quoted text

-----Original Message-----
From: Christopher Kings-Lynne [mailto:chriskl@familyhealth.com.au]
Sent: 17 June 2002 09:34
To: Marek Mosiewicz; PostgreSQL-development; PostgreSQL odbc list
Subject: Re: [HACKERS] Native OLE DB. What do you think about it

Are you aware that another team on the list is working on a
.Net provider? Maybe you could work with them?

.Net Provider people: speak up!

Chris

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Marek
Mosiewicz
Sent: Monday, 17 June 2002 4:34 PM
To: PostgreSQL-development; PostgreSQL odbc list
Subject: [HACKERS] Native OLE DB. What do you think about it

Hello everbody.

I have started work on native OLE DB Provider for

PostgreSQL. i think

it is really important to have native OLE DB proviader even

if there

is OLE DB to
ODBC Provider. Microsoft started to withdraw support for

ODBC and seems to

force to switch to OLE DB(eg VS .Net have limited support

for ODBC which

must be spearetly downloaded), so we could expect more such

moves. So I

started work on native PostgreSQL OLE DB provider. It slowly begin
to work. (it registers to system, shows property pages, connects to
database, and do first quries). Now I'm working on creating

resultset.

I would like somebody to help answer some questions:

1.is it safe to use binary cursors (basic types format e.g

date would

not change in future) 2.how could I control result type

(binary/ASCII)

for ordinary SELECTS ? 3.could ODBC driver mix auto-commit and
FETCH/DECLARE mode ? how it can handle such situation:
start select (fetch some data) /as I understand it should start
transaction silently/
update (it should commit as we are in auto-commit)
fetch more data.
next update (commit again)
4. maybe it would have sense to make some common library with
ODBC to handle
prepared statements and some kind of conversions (althougth

maybe not

becouse we convert to different types (OLE DB uses OLE

Automation types))

5. Is there any way to truncate PQresult in libpq ? I implement
fast forward
cursors so i have no need to store whole result (I can read

piece of data

and forget it when client read it from me). I think there

would be no

problem if I add some PQtruncate(PQresult *) to pqlib, but

maybe there is

any different way ?

I use ATL templates for OLE DB which is MS library and it can't be
compiled withot Visual Studio. (you have right to distribute ATL if
you bougth VS). So It would be not "pure" solution, but

starting from

scratch is to difficult, as I don't know COM prefectly.

Maybe somebody

will rewrite it later.

---------------------------(end of
broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

---------------------------(end of
broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an
appropriate subscribe-nomail command to
majordomo@postgresql.org so that your message can get through
to the mailing list cleanly

Import Notes

Resolved by subject fallback

#10

Martin Coxall

coxall@cream.org

over 23 years ago

In reply to: Dave Page (#9)

Re: [HACKERS] Native OLE DB. What do you think about it

Ahh, that would be us then :-) Yes, there is a (very) active .NET
provider project underway - it can be found at
http://gborg.postgresql.org/project/npgsql. Note though, that this is a
native .NET provider being written in C#, it is not OLE-DB (which would
certainly be a useful addition to the list of interfaces imho).

If that's the case, can I please make a suggestion: please liaise with
the Mono project's ADO.NET people (http://www.go-mono.com) as they are
doing exactly the same thing, and there's no need for duplication of
effort.

Martin

#11

Tom Lane

tgl@sss.pgh.pa.us

over 23 years ago

In reply to: Marek Mosiewicz (#7)

Re: [HACKERS] Native OLE DB. What do you think about it

"Marek Mosiewicz" <marekmosiewicz@poczta.onet.pl> writes:

1.is it safe to use binary cursors (basic types format e.g date would not
change in future)

Don't do it. The internal representations are NOT guaranteed stable,
and moreover any such thing will guarantee that your code can not talk
to servers running on non-Intel architectures. (I'm sure MS/Intel
would love you to do that, but don't.)

2.how could I control result type (binary/ASCII) for ordinary SELECTS ?

You can't, but it doesn't matter, see above.

regards, tom lane

#12

Marek Mosiewicz

marekmosiewicz@poczta.onet.pl

over 23 years ago

In reply to: Dave Page (#4)

Re: [HACKERS] Native OLE DB. What do you think about it

"Marek Mosiewicz" <marekmosiewicz@poczta.onet.pl> writes:

1.is it safe to use binary cursors (basic types format e.g date would

not

change in future)

Don't do it. The internal representations are NOT guaranteed stable,
and moreover any such thing will guarantee that your code can not talk
to servers running on non-Intel architectures. (I'm sure MS/Intel
would love you to do that, but don't.)

So I will not.

But any way is it difficult to froze basic types. I believe that producing
and parsing data takes some time both on server and client. Acctually it is
question about prepared statements, but I think it is not pay off. It can
take some time to parse parameters if you have many same queries updates
(very common situation e.g. sending back inserts/ updates from client).
you could then :
'Qselect * from a where a=? and b=?P<binary parameters>
<return binary result>
update a set x=? where y=?P<array of parameters - make the same query nth
times with different values>

Such prepared statments would not only benefit from cached plan but also
avoidance of parameter parsing and sending it - multiple times across
network -.

Most DB intefaces has some support for such batch execution so it could be
used (OLE DB JDBC) in it and gain speed)
It could be easy do decide to use exclusive little or big indian - such
conversion is many times faster than atoi(). I don't know if it is problem
to froze binary representaion of data but if it is not frozen then you could
never use bianry cursor from client).

I have no idea how diffcult it would be to implement so I don't know if it
it has sense, but it is only my propostion.

Show quoted text

2.how could I control result type (binary/ASCII) for ordinary SELECTS ?

You can't, but it doesn't matter, see above.

regards, tom lane

#13

Dave Page

dpage@vale-housing.co.uk

over 23 years ago

In reply to: Marek Mosiewicz (#12)

Re: [HACKERS] Native OLE DB. What do you think about it

-----Original Message-----
From: Martin Coxall [mailto:coxall@cream.org]
Sent: 17 June 2002 13:05
To: Dave Page
Cc: Christopher Kings-Lynne; Marek Mosiewicz;
PostgreSQL-development; PostgreSQL odbc list
Subject: Re: [HACKERS] Native OLE DB. What do you think about it

Ahh, that would be us then :-) Yes, there is a (very) active .NET
provider project underway - it can be found at
http://gborg.postgresql.org/project/npgsql. Note though,

that this is

a native .NET provider being written in C#, it is not OLE-DB (which
would certainly be a useful addition to the list of

interfaces imho).

If that's the case, can I please make a suggestion: please
liaise with the Mono project's ADO.NET people
(http://www.go-mono.com) as they are doing > exactly the same
thing, and there's no need for duplication of effort.

We have liased with them. Their provider is just a wrapper to libpq,
whereas ours is written from scratch.

Regards, Dave.

Import Notes

Resolved by subject fallback

#14

Peter Eisentraut

peter_e@gmx.net

over 23 years ago

In reply to: Bruce Momjian (#3)

Re: KSQO parameter

Bruce Momjian writes:

The following patch removes KSQO from GUC and the call to the function.
It also moves the main KSQO file into _deadcode. Applied.

_deadcode is nowadays known as CVS history.

--
Peter Eisentraut peter_e@gmx.net

#15

Bruce Momjian

pgman@candle.pha.pa.us

over 23 years ago

In reply to: Peter Eisentraut (#14)

Re: KSQO parameter

Peter Eisentraut wrote:

Bruce Momjian writes:

The following patch removes KSQO from GUC and the call to the function.
It also moves the main KSQO file into _deadcode. Applied.

_deadcode is nowadays known as CVS history.

Agreed, but _deadcode directories still exist, so I put it there.
Personally, I would like to see all those files removed, but I was
outvoted last time I asked.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

#16

Tom Lane

tgl@sss.pgh.pa.us

over 23 years ago

In reply to: Bruce Momjian (#15)

Re: KSQO parameter

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Peter Eisentraut wrote:

_deadcode is nowadays known as CVS history.

Agreed, but _deadcode directories still exist, so I put it there.
Personally, I would like to see all those files removed, but I was
outvoted last time I asked.

Perhaps we need a revote. I don't like _deadcode one bit ---
having that stuff in the tree just produces a lot of false hits
when I'm searching for things.

regards, tom lane

#17

Bruce Momjian

pgman@candle.pha.pa.us

over 23 years ago

In reply to: Tom Lane (#16)

Re: KSQO parameter

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Peter Eisentraut wrote:

_deadcode is nowadays known as CVS history.

Agreed, but _deadcode directories still exist, so I put it there.
Personally, I would like to see all those files removed, but I was
outvoted last time I asked.

Perhaps we need a revote. I don't like _deadcode one bit ---
having that stuff in the tree just produces a lot of false hits
when I'm searching for things.

Yes, that is my problem too. I can't tell you how many times I have
edited backend/optimizer/path/_deadcode/xfunc.c to keep it in sync with
the rest of my code changes.

OK, we have three who don't like _deadcode directories and want them
removed from CVS current (they will still exist in CVS). Does anyone
want them? I think Marc wanted them initially.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026